Lync, Strings and Cans

Like a lot of people in the Microsoft partner community, I’ve been catching up with Lync this year and digging in to the finer details with a few of my colleagues. One thing we wanted to understand better was the routing between two users over a LAN, a private WAN, or some other connection where all the necessary network ports would be open. Would these clients communicate peer-to-peer? If so, does it always behave the same way, how is it accomplished and what might go wrong?

First, consider an organisation with offices across multiple floors or buildings. Lync may be a very effective means of connecting these employees despite their relatively close proximity. If this traffic can route locally it can be a big plus – especially if there’s lots of media traffic. Second, consider an organisation with multiple branches. They invested in private WAN links to connect these branches and don’t necessarily want to route Lync traffic over their internet connections if they can avoid it. For some organisations these will be non-issues, since Lync traffic is optimised for the WAN, but for other organisations this may be important – particularly if they’re in a part of the world where internet connections are slow or expensive (or both). So we went about testing this with the Lync 2010 client and Office 365 users (the behaviour is the same with Microsoft Online IDs or federated users).

After monitoring this network traffic for a bit, I picked up on behaviour I didn’t expect to find. In this case I was making voice or video calls (sometimes referred to as “media” traffic):

• If all ports are open, media (voice/video) traffic will route peer-to-peer between the two client machines (with some important caveats to follow in a later post).
• If inbound traffic is blocked to one of the client machines (for instance by Windows Firewall or another network device), media traffic will route via the Office 365 Media Edge servers, while media traffic to the client machine that allows the inbound traffic will be transmitted directly from peer-to-peer.

I didn’t expect this would be the case, but it’s great that it behaves this way. The Lync client is smart enough to send voice/video data over two totally different routes if peer-to-peer communications are open in one direction and closed in the other. I’ll talk more about some caveats to this finding in a later post, but for now I want to consider what this tells us about this tool. Some of my assumptions about Lync were wrong and I think it’s worth pondering where those assumptions came from.

In search of a new conceptual model

At a glance, the telephone appears to be the best conceptual model for Lync, whether you’re texting, phoning or making a video call. There are even telephone icons in the Lync client, like this one:

In this telephony model, we assume there is one channel open in both directions, connected by patch panel on a switchboard. Some of us may even have an awareness of the “last mile” of cabling from a central office to personal or business premises.

Despite the obviousness of this comparison so far, we need to think about the other things Lync can do. The importance of this other functionality can be easy to overlook because this notion of a single open channel is such a deep association with voice communications – right back to the tin can and string. Even messenger communications evoke this sense of a single private channel, although we know it’s different than a phone. Perhaps this sticks in the same way because messenger often supplants a phone call and it’s nearly as immediate? Whatever it may be, the “why” is not important, but the phenomenon is.

Beyond telephony

Some of the other features we’re talking about here come from Live Meeting and other meeting workspace tools based on desktop sharing. Altogether, we’re looking at messaging, voice, video, desktop sharing, file transfers, whiteboards, presentations and polls. This looks a lot less like a phone call now. It looks more like a conference or a presentation, without having to leave your desk.

In a physical conference session, speakers may tag-team, or participants may ask questions, but typically a single participant will be sending information to the others when they have the focus. This is the essence of the medium: a group of participants observe one presenter at a time. There is one mixing desk, one source of video to the projectors, etc. If you’re participating in a conference with multiple speakers with microphones, communications suffer until a single participant regains focus. The best illustration of this point is a news panel discussion or a political debate. You get gibberish until things settle down again. Really this isn’t much different than any other form of communication, but there’s some pretty clear social norms involved.

This behaviour is clear to see in the Lync client when you have a multiple-participant video call, as the video presentation is automatically switched to the current speaker/mover. To this end, everything comes via a single source. If you prefer the technical jargon, “communication between the local and remote participants is mediated by a modality-specific multipoint control unit (MCU)“, in the Lync Server topology – in this case at Office 365. Think of this like a director in live television, who selects the camera to broadcast from many simultaneous inputs. In this case, that’s got a clever algorithm behind it rather than a person.

Now if you take this conference model and shrink it back down to two participants, while using the same tool, not a lot needs to change, but there is a new dimension to the communication – it’s private again now. Perceptually we are subject to this deeply-engrained association of a single private channel. At a user experience level, nothing really changes except that we always see the other participant because there’s no one else to switch to. At a technical level, and returning to the main point here, the communications can route peer-to-peer because there’s no need for mediation, assuming all of the necessary network ports are open. Put another way, the traffic routes in a clever way, if possible. The funky thing is that those routes needn’t be the same.

Two Strings and Four Cans

So how should we characterise this “conference”, in light of the fact that it’s private again now and that each client finds its own optimal route? To go all the way back to the tin cans and string, we need to clarify one thing. With a tin can and string, the can is both microphone and loudspeaker, but not at the same time. Now we have two strings and four cans, but each participant has one can acting as a microphone and another as a loudspeaker – each with its own piece of string. In our original example where one participant’s Windows Firewall was blocking inbound traffic, one of those lines of string has to go out the window and through the cat flap, while the other goes directly through an open door. To labour this strained metaphor further, that means you need a longer piece of string and that the messages on it will take longer to arrive.

Ultimately, I’m not sure how helpful this is as a replacement conceptual model, so I’ve contented myself with an acknowledgement that I’m synthesizing the illusion of a single channel, while smart stuff happens in the background to make sure that I get the best possible private communication over two.

There’s a few points that fall out of this at the network level:

1. It might be desirable to open up ports internally to allow this traffic to flow locally or across private WANs, if network security applications or devices would otherwise block it.
2. This isn’t as simple as looking at a phone call, or even a single HTTP “conversation”, in which a server responds to client requests over the client-initiated channel. This optimised routing will only occur if the sender’s traffic can reach the other participant over the optimal route – otherwise it falls back to the Lync servers.
3. It’s really useful to monitor this traffic from both clients, if trying to figure out what’s going on, because they may be doing different things.
4. All of this changes once you have more than two participants.

In my next post I’ll dive a bit deeper technically and step through how we monitored this behaviour. I’ll also reveal some important exceptions to what I’ve described here, which may throw a wrench or two in the works for bandwidth calculations.

For the sake of completeness, I should note that I’m not certain when Lync/Communicator started behaving this way, although for the purposes of setting the scene for my next post, I’m basically just concerned with Lync and the Office 365 context.