Video calls are just like telphone calls: you dial a number, get connected, and have your call. Video conferences are more complicated, but only for the same reasons that an in-person meeting is complicated: you have to identify everyone involved, invite them (and manage the acceptances and declines), organize the room, have an agenda, and so on.
And, just like telephone calls, there's a lot going on "under the hood" to make video calls work. This page covers the highlights of that process.
See the glossary if you encounter an unfamiliar term.
This section covers a basic call from one person to another.
The equipment that you use for video calls is referred to as a system. A system is a computer that knows how to do video calls. So, to place a call, make sure that your system is turned on. You then tell it who you want to call.
There are two ways to do this: E.164 number or IP address. (Your system may have a phone book or directory that has names. It's just storing the E.164 number or IP address for you.) E.164 numbers look like telephone numbers and IP addresses are the usual #.#.#.# addresses that you have seen before.
Once you've entered the address (either E.164 identifier or IP address), the system contacts its assigned gatekeeper. The gatekeeper does several things:
It then returns to your system the information that it needs to place the call.
Your system then contacts the system that you're calling and actually starts transmitting the call data.
Note that the data for the call - the actual audio and visual data - does not pass through the gatekeeper: that data goes directly between the systems. However, the gatekeeper does "keep its finger on the pulse" of the call and collects data on the call when the call completes. In this way, the gatekeeper can know when the bandwidth can be used for another call. Also, if you want to use additional call features (such as H.239), the gatekeeper is involved in enabling those features.
A video conference starts by being a number of point-to-point calls. Instead of each of the systems calling each other, they call a central MCU. So, if five people are in a conference, the MCU has five calls, one to each system. Each call operates as a basic point-to-point call.
In addition to being one end of each call, the MCU has the capability to combine the separate calls in a number of ways. It can always show everyone the same image (e.g., in a classroom situation), can switch which image it shows to follow whoever is talking, can have multiple images on the screen at once, and so on. Further, the MCU can bring in audio-only callers and provides other services, such as combining the signals from different types of video equipment into a whole.
So, when setting up a video conference, there are a few things to be aware of beyond the things that you need to do for an in-person conference. These things include the types of equipment and signalling used by the systems, the method used by the MCU for managing the image, and similar information. The MN.IT Video Reservations Center is happy to help you with this process and, in many cases, already has the information. (For example, MN.IT already knows the type of video equipment for all systems on its network.)
Some systems have a built-in MCU and can do small video conferences on their own.
When calling a site on the Internet or an ISDN site called using the telephone system, the call process is mostly the same as for a point-to-point call but has its differences.
Essentially, your call ends up going a gateway instead of the directly other, off-network system. The gateway acts as the other end of your call and places another call to the other system using whatever different video protocol is required. It then connects the two calls. Unlike the case with gatekeepers, the gateway is actively a part of the call and the call data actually passes through the gateway. If an MCU is involved in a call, it can act as a gateway in many cases (one of those "other services").
Our system supports downspeeding which means that a conference is allowed to be set up with some calls having a smaller bandwidth than originally requested in order to enable the call to fit within the available bandwidth. However, it is better to consider the available bandwidth when planning the conference.
Some features such as H.239 in effect place additional calls when they are used. And, while there may be adequate bandwidth for the original call, there may not be enough bandwidth for the additional feature. In such cases the original call won't reduce its bandwidth, so the feature won't be available. However, if you place the original call at a lower bandwidth (e.g. 192 kbps instead of 384 kbps), there may be enough bandwidth to permit use of the feature.
