Unified Communications with Microsoft

Since I will keep expanding my lab Lync deployment with Enterprise Voice (I plan to test few new products, as for example – Ferrari Electronics' PCI certified Lync Gateway), now is a good time to configure and test Media Bypass functionality. MB is an awesome feature and I am excited of the fact that is now included. As an “old school” LCS/OCS guy, the bare thought of virtualizing anything that touches RTP makes me itch, but… this is another story…

Configuration of Media Bypass is described here: http://technet.microsoft.com/en-us/library/gg413028.aspx. I will simply follow the steps and later run some traces to verify the functionality.

As described, we have two options – to “force” (via Global settings) “always bypass” which I find not such a good idea, especially if our environment consist of multiple regions and sites where the WAN and inter-site links could be impacted at any time. Instead, I will use “sites and region configuration” option.

Next, I will enable Media Bypass on my only (as of this moment) Trunk.

…and of course, Commit the changes.

***It is important to understand the following statement:

“If you have already optionally configured call admission control (CAC), another advanced Enterprise Voice feature, note that the bandwidth reservation performed by call admission control does not apply to any calls for which media bypass is employed. The verification of whether to employ media bypass is performed first, and if media bypass is employed, call admission control is not used for the call; only if the media bypass check fails is the check performed for call admission control. The two features are thus mutually exclusive for any particular call that is routed to the PSTN. This is the logic because media bypass assumes that bandwidth constraints do not exist between the media endpoints on a call; media bypass cannot be performed on links with restricted bandwidth. As a result, one of the following will apply to a PSTN call: a) media bypasses the Mediation Server, and call admission control does not reserve bandwidth for the call; or b) call admission control applies bandwidth reservation to the call, and media is processed by the Mediation Server involved in the call”.

Simply said – do not enable Media Bypass if you intend to utilize Call Admission Control due to a slow or unreliable WAN links because if MB is enabled, CAC will not be respected.

Now gets a little tricky. We must associate each subnet on our network with a specific network site. First, I will define at least one Network Site:

Next, I will use Control Panel to define one subnet in my environment:

…and another with Lync Server Management Shell:

Quick check of my Site properties shows that the subnets are now associated with this site.

Now I should expect Media Bypass to work or, should I? Fact is – Lync clients receive such information via in band provisioning and so, in order to test immediately, I will log off and login back to Lync from a client on 10.8.0.0 subnet.

There are several ways to verify if MB works. As Jens Trier Rasmussen described in this post: http://blogs.technet.com/b/jenstr/archive/2011/04/14/media-bypass.aspx, I could check my Monitoring server for Call Information or use Snooper or… run Wireshark and see if RTP will flow between my Audiocodes Mediant 800MSBG and my PC (Lync client).

Indeed, it worked as expected.

After few busy weeks, I finally found few hours to play with my lab. This time I will install Achieving and Monitoring roles of my Lync environment.

While Archiving pretty much depends of your company policy requirements, Lync admin MUST install Monitoring, especially if Enterprise Voice is deployed. Monitoring collects not only CDR (Call Detail Record), but also Quality Metrics for every call.

I have MS SQL server already setup on machine with FQDN sql01.lynclog.com. I created a named instance for my roles (I intend to co-locate the databases) called ARCMON.

First, I will add my instance to the SQL store in Topology Builder.

Next, I will add the Monitoring and Archiving roles…

…select the pre-defined SQL Store…

…and associate my server(s) with it

Next, will do so for the Archiving role as well.

It is highly recommended to use a dedicated share for Archiving, typically on the SQL server itself. I could use the file share defined for my first server:

…but what if later for some reason this server is decommissioned? In this case, this would break the Archiving of all servers I could have at later stage. So, I will create a file share on my SQL server right now…

…and use it in Topology Builder.

Last step – Publishing the topology and examining the To-Do-List.

I will now run Lync Installation media on the SQL server.

At this point, I will verify that the databases are installed using SQL Management Studio

***Note that in the line “SQL Server Reporting Services (SSRS) instance” I will use the FQDN of the SQL server (and not the default FQDN\INSTANCE as it was offered), because I configured my ReportServer to run on the default instance only.