Haiku #180

[NextHop_Team]

First published on TECHNET on Aug 30, 2011

There are known knowns and

There are unknown knowns. Like, say,

Media bypass.

You know what's the worst thing about writing a daily haiku on Lync Server PowerShell? Well, OK, the second worst thing: obviously the worst thing is having to get up early and actually do some work every single day . (We still think there should be laws against that.) At any rate, the second worst thing about writing a daily haiku on Lync Server PowerShell is this: sooner or later, you're going to have to cover a set of cmdlets, and an underlying technology, that you know absolutely nothing about.

Why do we mention that on the same day that we're writing about the New-CsNetworkMediaBypassConfiguration cmdlet? Oh, no reason. It's just something that popped into our heads.

At any rate, New-CsNetworkMediaBypassConfiguration is a very nice little cmdlet and you should use it any time you need to create a new network media bypass configuration. See you tomorrow!

Nah, hey, just kidding. Well, sort of: New-CsNetworkMediaBypassConfiguration is a very nice little cmdlet and you should use it any time you need to modify your network media bypass configuration settings. And in the next few paragraphs, we'll explain what that means.

Well, sort of.

To explain what media bypass is all about, we have to first journey back in time to a very primitive and long-forgotten era, an era where there was no such thing as Microsoft Lync Server 2010. (Yes, we know. But try to picture such a time as best you can.) Back in those days (a time that paleontologists refer to as the Office Communications Server 2007 R2 Era), the signaling portion of a call made with Office Communicator and the media portion of that same call all had to pass through a Mediation server before it could be forwarded on to a PSTN gateway or an IP-PBX. (In other words, before that Communicator call could be sent out on the "regular" telephone network.) What's wrong with having both the signaling portion of a call and the media portion of a call routed through a Mediation server? Well, nothing really: the system definitely worked. On the other hand, the more hops introduced into a network path the more chances you have for something to go wrong. (And, as you might expect, more hops also equals slower transmission times.) Likewise, the Mediation server had to convert the signal to a codec that could be understood by the gateway. The more times you have to decode and encode a signal the more chances you have for something to go wrong.  (And, as you might expect, more decoding/encoding also equals slower transmission times.)

In other words, it was a system that worked, but it was also a system that was ripe for improvement. And if that isn't the perfect lead-in to media bypass, well, then we don't know what is.

OK, so then what is media bypass? Well, suppose you have the right kind of gateway, a gateway that supports media bypass. (And knowing whether or not you do have the right kind of gateway is something that goes way beyond what we can talk about today … or that we could ever talk about, to be perfectly honest. But see this page for more information.) If you do have the right kind of gateway then you can enable media bypass. In turn, that means that the media portion of a call does not have to pass through a Mediation server. And that means fewer hops, and fewer encoding/decoding sessions. That makes for faster and more robust calls, and saves enormous wear-and-tear on your Mediation servers. So much so that Mediation servers no longer have to be stand-alone machines; instead, they can be collocated on your Front End servers, saving you money on both hardware and software.

Note . So can't you just throw out your Mediation server altogether? No. Remember when we talked about the signaling portion of a call and the media portion of call? With media bypass, the media portion of a call can bypass the Mediation server, but the signaling portion still has to be routed through the server.

OK, so then what's the New-CsNetworkMediaBypassConfiguration cmdlet for? Well, New-CsNetworkMediaBypassConfiguration has one purpose in life: it creates a new media bypass settings object, an object that determines if (and, to a certain extent, how) media bypass is implemented. In turn, that object can then be used to configure the MediaBypassSettings property for your network configuration settings.

Actually, we're a little confused ourselves. So let's look at an example:

$x = New-CsNetworkMediaBypassConfiguration -AlwaysBypass $True -Enabled $True

Set-CsNetworkConfiguration -MediaBypassSettings $x

So what have we done here? Well, in the first command, we've used New-CsNetworkMediaBypassConfiguration to create a new media bypass settings object, an object that gets stored in a variable named $x. In this example, we've set the AlwaysBypass parameter to True, meaning that we want to attempt to use media bypass on every call.

Note . Would you ever not want to attempt to use media bypass on every call? Yes. For example, if you're using Call Admission Control (CAC) you would actually want CAC to determine if, and how, media bypass should be used on a call.

Oh, and we also set the Enabled property to True, which simply enables media bypass on the global scale.

After creating the media bypass settings object, we then use the Set-CsNetworkConfiguration cmdlet to set the MediaBypassSettings property to the value of $x. Because you can only have a single, global collection of network configuration settings, this will potentially enable media bypass for all your gateways.

Why did we say "potentially?" Well, even after you've enabled media bypass on a global scale, you still need to enable it for each individual gateway. (If you didn't, then media bypass would automatically be enabled even for gateways that don't support the technology.) To enable media bypass on an individual gateway, use the CsTrunkConfiguration cmdlets.

Keep in mind that there's no Set-CsNetworkMediaBypassConfiguration cmdlet and there's no Get-CsNetworkMediaBypassConfiguration. But that's not a big deal. You can always review your current settings by running this command:

Get-CsNetworkConfiguration | Select-Object –ExpandProperty MediaBypassSettings

And what if you want to change your current settings? That's even easier: just repeat the same process we used a minute ago. For example, this set of commands disables media bypass:

$x = New-CsNetworkMediaBypassConfiguration -Enabled $False

Set-CsNetworkConfiguration -MediaBypassSettings $x

That replaces the existing media bypass settings with a new media bypass object in which the Enabled property is to False and all the other property values (such as AlwaysBypass) are set to their default values. What if you wanted to change just one property value of your media bypass settings? That's fine. All you have to do is retrieve the current media bypass settings and store those settings in a variable (e.g., $x). You can then change the property value in question (for example, setting AlwaysBypass to False) and then use Set-CsNetworkConfiguration to write the changes back to Lync Server.

In other words:

$x = (Get-CsNetworkConfiguration).MediaBypassSettings

$x.AlwaysBypass = $False

Set-CsNetworkConfiguration -MediaBypassSettings $x

And there you have it: everything we know (and a few things we didn't even know we knew) about the New-CsNetworkMediaBypassConfiguration cmdlet. And, with any luck, this will be the last time we have to talk about a cmdlet, and a technology, that we don't know anything about.

Except maybe when we get to the CsCertificate cmdlets. Or the CsDatabase cmdlets. Or the – well, never mind: we'll cross those bridges when we come to them. See you tomorrow.