Video conferencing requires conference servers (aka bridges) to be available when people want to meet. How do we ensure that people can show up to meetings and that they are not rejected at the door (busy signal when dialling into a meeting)? This post is aimed at the IT and network operations person, and although a part of my series on the next-generation multi stream video architecture, it is more on the practical side than earlier more “under the hood” posts.
Classic video conferencing is based on scheduling of meetings and the need to reserve meeting rooms and conferencing resources at the time of scheduling. The person scheduling the meeting adds the people and the meeting rooms to the calendar invite, and a video scheduling system will work in the background to calculate how many video conferencing resources will be required for the meeting and reserve those resources (on a video bridge) to ensure that the meeting will happen (Cisco happens to have a brilliant product called TMS doing this among other things). Each room will automatically be pulled into the meeting hosted on this video bridge, and the participants will walk over to the meeting room closest to where they are.
However, people have started to use their own personal Jabber clients (or Spark clients) to join a meeting, or they have a video system, like the Cisco DX-series, on their desktop. This complicates the calculation of how much video conferencing resources are required to host the meeting. It is like determining the size of the conference room you should book at a hotel when you plan a meeting without knowing how many will participate. Who will walk over to the meeting rooms? Who will join from a desktop system? Who will join on their mobile phone through Webex? The needed resources can still be estimated (if the reservation system knows which participant has a desktop system and not), but it’s now an estimation, not an accurate calculation.
If you have followed my blog series on the next-generation multi stream real-time video architecture, you know that there are also two more innovations that impact the calculation of resources: media elasticity and multi stream participants. Without going into details, the high elasticity of new media streams (how much bandwidth and conferencing resources they require) and the flexibility in how many media streams each participant sends and consumes, make it impossible to estimate up front how much video conferencing resources a given participant is going to consume.
So, is this the end of scheduled video conferencing? Not at all. Most people like to (and need to) schedule meetings, but they also meet ad-hoc. I see meetings as one of three types: scheduled (organised around a set of participants and a specific time into the future, possibly recurring), ad-hoc (organised here and now by pulling a group of people into a meeting), and rendezvous (organised around a venue and a time, but with less focus on the participants, could be 2 people or 100). If these types of meetings need to be supported in your organisation, and the calculation of resources required is impossible, how then to ensure that you have enough conferencing resources available and people are not met by a busy tone or disconnected when trying to join a meeting?
The answer is the end of hard reservation of conferencing resources on video bridges. The reason is that in this new world the only way you can ensure that enough resources will be available is to always reserve for the worst case. This will mostly leave a lot of resources running idle. Most organisations do not have a budget for this. As an IT guy responsible for the SLA (Service Level Agreement) and avoiding that the executive gets a busy signal, you still need a way to make sure you have enough resources available. You need to plan adding more capacity if usage picks up, and you need to monitor the actual service delivered to make sure that the right service quality has been delivered.
There is one important thing you need to understand in delivering a service: you can never guarantee that everybody will get the optimal service all the time. No matter how many resources you have available, somebody can always decide to host a huge meeting at the same time as another part of the organisation has an all-hands meeting. If you try to do hard reservation and scheduled meetings only, you will give a denial of service at scheduling time, and the person hosting the meeting needs to find another way of having the meeting or move the meeting to a different time. It’s still a denial of service, though, and the organiser was not able to host the meeting.
If you instead allow scheduling to happen without reservation, you may occasionally find that a user gets rejected at call time (or get audio only) because there is no space left. This is similar to being rejected at the door of a meeting because there are no more seats. You can manage the probability of this happening though, by making sure that you have enough idle capacity to handle a peak in usage. How much extra capacity you want, is based on your budget and how often you are willing to let users be rejected when trying to join a meeting. When you move to such capacity planning and monitoring instead of hard reservation, you monitor the average and peak hour usage levels and add more bridge resources when needed. A side note: some meetings are so critical that denial of service at call time is unacceptable. Idle resources can for these cases be accepted. It is also possible to have a separate pool of resources reserved for such meetings.
Earlier, bridge capacity had to be bought as expensive ports. Newer licensing models allow you to license each individual or video room in your organisation to host meetings, regardless of how much is actually used. As usage grows in your organisation, you then only need to add more hardware to host the meetings. If you use virtual bridges, these are standard, general-purpose servers.
So, if your organisation is looking at moving beyond meeting room video and/or to invest in more modern, multi stream enabled real-time video, you should start planning the move from reservation-based resource planning to capacity planning.
RSS - Posts