Securing your Videoconferencing Codec: Call Security


Now that we have talked about all the mundane aspects of keeping your videoconferencing systems secure, let’s get into the Jason Bourne, James Bond, and A-Team stuff and look at how we can protect our videoconferencing conversations from being intercepted.

Auto Answer Settings

The first step in protecting the security of a videoconferencing call is to make sure that you know when someone is connected to your system. When a call is made to a videoconferencing system, its auto-answer settings determine how that call is handled by the receiving system. If your system is setup to automatically answer all calls, someone can call into your system at any time and surreptitiously listen into conversations in the conference room or, depending on the sensitivity of the microphones, in adjacent rooms.  In general, there are three ways that you can set the auto-answer configuration on a system.

Auto-Answer Off
With this setting, any calls that come into a system will generate an on-screen message (usually along with an audio alert) detailing information about the caller and asking if the call should be answered or rejected.  In order for the call to be accepted, a person will have to be in the room and specifically make a choice to accept the call. If no choice is made within a certain time period, the system automatically rejects the call.  This is the most secure setting, since it requires a person in the room to be aware of the inbound call and make a conscious decision to accept it.  It is also the most annoying setting, because if no one is there to answer the call then the call will be rejected, and the person placing the call will have to redial if they want to try to connect again.

Auto-Answer On
With this setting, any calls to come into the system will be automatically answered. The two systems will conduct a brief negotiation of protocols and will start two-way video and audio communications. No interaction from a human is required which makes this the least secure setting. With this setting someone could potentially dial into your conference room, mute their video and audio, wait for people to come into the room, and be able to see and hear them without their knowledge.  However, this is the most convenient setting with the least steps required to get the call up and running. This might be an acceptable setting if your system is not accessible through the Internet and can only be reached from your local network.

Auto-Answer On/Mute On
This setting is the same as auto answer on, but the local system will automatically mute the microphones in the room.  That way, the call is connected quickly but someone in the local room must interact with the system before the remote participants can listen to any audio coming from the local room.

Security is always a balance between convenience and securing a system.  You don’t want something so secure that it becomes annoying to use, nor do you want something that is so insecure that it leaves you vulnerable.  For me, the the last option, auto-answer on and auto-answer mute on, is a good compromise and what I recommend to my clients. With this setting, if the local participants are running a little bit late and no one is in the room to answer the call, the call will still get answered and they can simply unmute when they get to the room. Likewise if someone calls into the videoconference a little early and another meeting is still occurring in that room, the caller will not hear what is being said.  Yes, I know our spy could know how to read lips or glean other information from what is going on in the room, but how likely is that really? Again it’s a matter of balancing convenience with security.

Note: Most systems will also have a setting for “do not disturb.”  In this mode, all inbound calls are rejected without any notification to the users in the local room. I recommend that this setting should be used sparingly.


Meeting Passwords

In many configurations, participants will dial into a virtual conference room that is hosted on a Multipoint Conferencing Unit (also known as MCU or a bridge). For example, all participants might dial to connect to the MCU ( and the virtual meeting room number 4231. There have been reported cases of company employees dialing into a virtual meeting room, muting their video and audio, and then listening to the meeting without anyone knowing they were in the meeting. Limiting the distribution of the dial string for sensitive meetings is a good idea.

Some MCUs are also setup with an auto attendant, so that if you dial the MCU, you will be presented with a list of meetings to join.  In order to add some security, a meeting password can be set so that once a participant connects to the virtual meeting room, they also have to enter a passcode. This will increase security, but makes it harder for people to join the call (sometimes the users will have to change the setting for the remote so that pressing a number no longer changes camera presets, but produces DTMF tones). Turning off the auto attendant is also a good idea, but can make it more difficult for people to get dialed into the conference.

One other solution is to configure the MCU so that it shows all the participants and the name of the system they are calling from at all times. So, if you see a quadrant of the screen that says (Conference Room Alpha), you know that system is dialed in, even if you don’t see video or hear anyone. This is not available on all MCUs, but I think it is the best solution if you are worried about unauthorized users dialing into your meetings.

Call Encryption

The last and least likely way that someone can get access to a videoconferencing call’s content is by intercepting the data on the network and listening to (and perhaps watching) what is happening. There are several tools that could allow someone to do this.  A number of these tools are specifically designed for intercepting and hacking into audio calls made over the Internet. However, videoconferencing protocols and the audio protocols used for VoIP are closely related, so these tools can potentially be used to attack a videoconference.

The solution to this is to encrypt the call. All current generation videoconferencing systems have robust encryption built into the system. However, encryption comes at a cost in performance. The required processing may mean that there will be sacrifices in resolution and/or frame rate of your call. As such, you might not want to use it all the time.

Organizations that deal with sensitive information, for example healthcare records or financial records, may be under a legal obligation to make sure the call data is secure. However, they don’t necessarily have to enforce strict policies that every call is encrypted. It could be that the internal network is designed to be secure, and entirely within the control of the organization, and therefore would not require encryption for internal calls.  However, when a call goes outside of the local network, it might need to be encrypted.

Like the auto-answer function, most systems have three settings for call encryption:

  1. Never: Don’t encrypt any calls, even if the other system(s) in the call can.
  2. Strict: Encrypt every call. If the other system(s) in the call can’t or won’t encrypt, then reject the call.
  3. Auto: Try to encrypt whenever possible, but it is OK to connect with systems that can’t or won’t encrypt the call.

The encryption setting that you choose here will depend on your legal obligations, what your organization discusses in meetings, and how paranoid you are!

Note: Lately some people have been more concerned about the fact that the US government has the ability to tap into Internet traffic, intercept that traffic, and listen in to our conversations, perhaps even if encrypted. There is some evidence from the leaks by Edward Snowden, that there are tools available to do this for videoconferencing. Interestingly, the military uses its own encryption devices for videoconferencing.

What are your thoughts? Have you had problems with physical or call security? Ever had an eavesdropper on a call? What more should people be thinking about when it comes to security? Comment below!


About Author

J Scott Christianson is a successful instructor and business owner with more than 23 years of experience in networking, videoconferencing technology, and project management. A Project Management Professional (PMP), Scott has worked on more than 400 videoconferencing projects. He currently serves as an Assistant Teaching Professor in the Trulaske College of Business at the University of Missouri and remains actively involved in videoconferencing technology and applications. The opinions expressed in Scott's commentary are his own, and are not representative of Let’s Do Video or the University of Missouri.

Leave A Reply