Lync: Programmatically switching video device during a call

This is a post about changing the active video device whilst a call is in operation, from an application running in UI Suppression mode.

Actually changing the active video device is quite easy, and you do it the same way whether you’re in a call or not.

The DeviceManager class maintains a IList of Device for both Video and Audio. Additionally, there are properties for ActiveAudioDevice and ActiveVideoDevice. Both these are read/write, so it’s a quick job to expose this information to the user to allow a choice to be made.

But, there’s a problem if you try and do this whilst a call is in progress.

To give a bit of context, it’s useful to see how this is handled in the Lync client. Unfortunately, this will involve several pictures of me from different angles.

Let’s start in an existing call. Notice my video feed is active and shown in the corner:

There’s no commands in the call dialog window to change the video feed, even though they are for audio (more on this in a moment), so it’s not immediately obvious. However, you can still access the main Lync window, so you can bring up the Video Device options to choose another device. Notice in the screenshot below that the feed is different from the first screenshot.

When you click OK, rather than switching the video feed, Lync actually stops the video on your current call. If you mouse over the video window, you’ll notice that it has “paused” the feed:

Notice how my feed isn’t displayed – it’s not active. If I now click “Start My Video”, the video feed resumes, on the new device:

This is very different behavior from changing the audio feed. That’s instant, it just happens and the new audio is switched in without you needing to do anything. I imagine there must be some problem with doing this on video, because it feels like they’ve tried to hide the problem by not including an option for in-call video device switching on the client.

It also presents a real issue if you are developing an client running in UI Suppression Mode.

Unfortunately, there are no events such as DeviceChanged you can subscribe to, (I couldn’t find any anyway) which is a bit of shame, and would be a good addition to the DeviceManager class. I also looked at the various events of the AVModality class, which also seemed like a sensible place to raise events like this, and checked the list of properties it has. Nothing would tell me when the ActiveVideoDevice property was changed.

There is one thing you can rely on though. Once you have the AudioVideo modality of the call, get the VideoChannel property, and subscribe to its StateChanged event. One of the event arguments is ChannelState, which is an enum as defined below:

 public enum ChannelState
    {
        Connecting = 1,
        Inactive = 6,
        Invalid = -1,
        None = 0,
        Notified = 2,
        Receive = 4,
        Send = 3,
        SendReceive = 5
    }

From looking at the client, we now have a pretty good idea about what’s happening to the video behind the scenes. So, it’s not a great surprise to find that when you change devices, the state changes from SendReceive to Receive. That’s in-line with what we see happening – the video feed stops.

What you do here is up to you. You may already be handling this state, and either hiding the client’s own feed window (if you have one), or processing it as an error, or ignoring it, or whatever. But if you can work your existing logic around it, when handling a state change from SendReceive to Receive, it could mean that the device just changed, so if you’ve allowed the user to do this in your app, it’s worth attempting to reconnect the video. You don’t have to do anything clever to pick up the new device or anything, Lync handles that. Reconnecting the video channel exactly as you did when you initiated the call will work, and when it connects, it will be using the new device.

Again, it’s worth pointing out that, even in Suppression mode, changing the ActiveAudioDevice is seamless, and works without needing any intervention. It’s just video which doesn’t, and requires this slightly counter-intuitive ‘hack’ to get it working.