1. Introduction
  2. Overview
  3. How to become a member
  4. Technical documentation

Introduction

The Mconf Academic Network described in this page was first proposed during the Terena Networking Conference in 2012 (view the presentation recording). It aims to create a collaborative web conference network in which institutions can provide resources (a web conference server to be a part of the infrastructure), and then gain access to a scalable and distributed web conference service. This service is accessed through different web portals, such as mconf.org or the web portals provided by the institutions.

The web conference servers in the network are shared: every institution that’s a member of the network might have its users using any server in in the network, even servers provided by other institutions. The server that will be used is decided at the moment a web conference is created and this decision is based on several factors. The server selected might be, for example, the one that’s nearest to the user that’s creating the conference, or the server that has more resources available (e.g. CPU and memory) at the moment the conference is created.

The main advantages of becoming a member of the network (in comparison with an isolated infrastructure) are:

  • High availability: In a network with multiple servers to fulfill the same purpose (i.e. multiple web conference servers) the availability of the service will be clearly higher than in an isolated network with fewer servers (the cost to maintain the same number of servers available in a shared infrastructure is clearly higher). So institutions mutually benefit from the servers provided by other institutions, reducing the cost to maintain the infrastructure and increasing the availability of the service. Furthermore, the availability of the core services (load balancing and monitoring) is guaranteed by the maintainers of the network.
  • Accommodation of usage peaks: To accommodate usage peaks institutions normally have to provide a greater amount of resources than is needed for day-to-day usage, and these extra resources will probably be idle most of the time. It is clearly not a cost-effective solution. In a distributed network the institutions can provide what is needed for their normal usage and benefit from the other servers in the network to accommodate eventual usage peaks.
  • Resource optimization: Similarly to the accommodation of usage peaks, the usage of the resources in the network is also optimized if we consider that they are distributed across the globe, in different time zones. When is normal to have a high usage of web conferences in a region of the world, in other regions the servers might be idle. Furthermore, the distribution of servers around the world allows the system to use geolocation information to decide which server to use for a meeting, thus reducing the distance and the delay in the communication.
  • Low cost: Currently the cost for an institution to join the network is fairly low. It has to provide a server with enough resources (includes CPU, memory, and network, mostly).
  • Monitoring: All servers in the network are being constantly monitored. This allows us to detect problems in the network and warn the institution responsible for the servers up ahead. This also prevents users from using malfunctioning servers.
  • Usage reports: The network core generates usage reports that allow the institutions to see how they are using the network and how the resources they provided are being used. These reports can be used, for instance, to show which institutions should provide more (or less) resources and why they should do it.
  • Open source: In an open source environment, the more people use the system, the better it will become. When several institutions are using the same solution, testing it, thinking about it, and possibly collaborating with the development, everybody is favored!

Keep reading this page for more details about the network’s infrastructure and to learn how to become a member.

Overview

The image below shows a simplified version of the network’s architecture that we will use to explain how the network is organized and show the components take are part of it.

Mconf Network's architecture

Mconf Network’s architecture

At the right side of the image, we have the network’s back end. This back end is formed by a group of servers that form the core of the network. The back end is shared among all institutions that are connected to the network. The elements in the back end are: (1) the cloud of web conference servers; (2) the monitoring system; and (3) the load balancer.

  • (1) The cloud of web conference servers: This cloud is formed uniquely by Mconf-Live servers (see more about Mconf-Live in this page) that can be located anywhere in the world. The servers provided by the institutions are placed in this cloud and will be accessible to anyone that uses the network. These servers are stateless by design: once a meeting ends, all its resources will be lost (expect the recording of the meeting, in case it was recorded). This make it extremely simple to add new servers to the network, and also to remove and update servers. These servers are maintained and automatically updated with the use of Chef, and all the installation scripts and code that runs in these servers are open source and available for anyone to inspect and improve.
  • (2) The monitoring system: The network has a monitoring server called Mconf Monitor, a solution currently based on the well known monitoring system Nagios, that monitors all servers in the cloud. When a new server becomes part of the network, it instantly starts being monitored by the monitoring server. Several metrics are monitored for each server, such as the CPU load, memory usage, bandwidth consumed, web conference service usage (e.g. number of participants and number of rooms), availability of the ports used by the service, and several others.
  • (3) The load balancer: The last element of the network is the Mconf Load Balancer. It is responsible for deciding in which server a meeting should be created in order to balance the load among all servers in the cloud. It uses the metrics collected by the monitoring system to constantly avail the servers in the infrastructure, so when a user requests a new web conference room, the load balancer uses all the monitoring information to select the most appropriate server to run the conference. It also uses the geographic location of the servers and client to decide for a server that’s closer to the client. The Load Balancer has also a Dashboard, a web page that shows in real-time the state of all servers in the network. You can see the dashboard at: lb.mconf.org. The load balancer is the only software in the network that is not currently open source.

At the left side of the image, we have the network’s front ends. The front ends are the websites or web portals that provide access to the web conference infrastructure, plus the recording servers. In the image you can see two possible front ends: a software called Mconf-Web and an instance of Moodle with a plugin that provides access to Mconf. Every institution connected to the network is encouraged to have its own web portal (or even multiple web portals, as shown in the picture) that will provide access to their users. And if an institution doesn’t want to have a web portal, their users can use mconf.org.

Mconf has an open source application called Mconf-Web that is used at Mconf.org and that can be customized by other institutions that want to use it. To know more about how to use and customize Mconf-Web or how to integrate your web application with Mconf, check our wiki pages.

Institutions can also provide a recording server that will be responsible for processing and storing the recordings created by the institution. When a user records a meeting, this meeting is first captured and stored in the Mconf-Live server where the meeting was held and later it is safely moved to the recording server provided by the user’s institution. With this architecture institutions have full control over their recordings and can define their own methods and rules to manage them. You can read more about the recording infrastructure in this page of our wiki.

An important aspect of the network that you can see in its architecture is the fact that institutions have control over their users and their data, including all data stored in the web portals and all recordings, as already mentioned. So institutions can, for instance, define their own authentication methods and their own rules over the use of resources in the network (e.g. an institution can define who can create meetings and who can record meetings).

The web portal on mconf.org provides free access for anyone that wants to use the network. This web portal is provided by Mconf.org in exchange for the services of monitoring and maintaining the network. Mconf.org also provides its own an Mconf-Live server to the pool of web conference servers.

How to become a member of the network

To become a member of the network, the first thing we ask is that you read and agree with the terms and conditions to join the network. It’s a rather succinct document where we included the most important factors that institutions should be aware of before entering the network. So take some time to read it:

Read here the terms and conditions to join the network

After reading the terms, you can proceed to the technical part: how to install a server and join the network. You will see that it’s very easy to setup a new web conference server and set it as part of the network. We keep the technical documentation in our wiki and we offer all the support through our mailing list (or see the contact page for other ways to contact us). Refer to the last section of this document for the links pointing to the proper wiki pages.

You will see that there’s a script to install everything out of the box, and when it’s done we will see your server in our monitoring system. After a validation test, we will enable this new server to join the network, so you will soon see your server on the Mconf Dashboard. The load balancing logic takes into account the geographic location of the users, so when you open a new conference room, the new room will be opened most probably inside the new server you just set up.

Also, you may want to have your own web portal in the network. It could be, for instance, a the website of your institution, a new instance of our web portal Mconf-Web, or a CMS system. The load balancer implements an API (read about it here, here and here), so if you want to integrate the web conference service with another portal, you will be using this API. After that we will provide you a security key that you can use to access the entire infrastructure.

Technical Documentation

The technical documentation of how the network works today can be found at our wiki pages. See below the links to the pages related to the network: