Month: February 2016

As I’ve said previously on my site here I spend most of my time designing Unified Comms systems, now predominantly around Microsoft architectures.

I also get involved in normalising/rectifying/stablising systems that have already been deployed. With UC platforms it’s not that hard other a solution to 80% deployed and operational with little UC knowledge…and yet it’s that last 20% of deployment that can utterly ruin a user experience.

Anyway, on that ruining a user experience piece, two networking things that I see a lot of that tends to fly under the radar at the design phases are VPNs, and Proxy setups. Media does not play well with a proxy system…but nor do VPNs. I’ll talk about the Proxy issues in another post, but lets look at VPNs first.

So, whats the beef with VPNs? It’s really down to the fact that operating over a VPN can seriously degrade media performance to the point that it irritates the users. The reason for it is that the process of pushing traffic through an encrypted VPN tunnel seriously impacts jitter and latency figures for the media connection – mainly through the additional workload of additional encryption and decryption. Lync/Skype traffic is already encrypted – signalling via TLS and media via SRTP. so pushing it through a VPN just means you’re encrypting already encrypted traffic. Hardly efficient.

Now, Microsoft’s architecture has a model in place for just this scenario – the Access Edge topology. Media relayed through the Edge is designed to provide a high quality experience over uncontrolled networks. 

The problem is though how do you stop users sending their traffic over the VPN when they want to make a call? It’s not as if you can ask them to disconnect from the VPN to accept or make a call can you? Well, there is a way, but it does take a bit of planning – namely configuring a split tunnel VPN configuration.

What you want to achieve is all your normal traffic goes via the VPN except any Skype/Lync traffic – you want that to go to the Access Edge servers. Split Tunnel VPNs are not that unusual and most VPN platforms support the capability – there’s something else you need to consider however, and that’s the client connectivity logic.

Imagine the scenario where you enable split-tunnel on your VPN so that your Lync clients can connect to the Access Edge servers. The problem you’ll run in to is that the Lync client will first check for internal connections to the Front End servers using either LyncDiscoverInternal or other DNS entries – if it find them and the front-end servers then it will connect via the VPN tunnel regardless of the ability to connect to the Access Edge.

So, how do you fix this? Well, explained simply the way to fix it is to ensure that not only do you allow the split-tunnel for the client but you also block access to the Front End Servers. Essentially you need a firewall rule that blocks:

There’s numerous ways of achieving this. You can even achieve it using Windows Firewall policies for example, however for the most part it’s easier to configure at either a firewall or VPN platform level. The Windows firewall policies for example wouldn’t apply to Mac users or people using systems that don’t receive those policies.

VPN configurations are one of those things that add to the quality of experience of using a platform, making the user’s situation stable, repeatable, and positive. Will the product work through a VPN? For the most part, yes – your users won’t thank you for it though.

I’m working on a site at the minute that has disjointed extension/DDI numbers – that is their extension numbers in no way match their assigned DDI. Throw in some routing to legacy PBX platforms…and your dial plan gets ‘interesting’. 

Anyway, one thing I wanted to do was to turn on the ability to view extension numbers in the Skype client. What do I mean I hear you say – well, consider the normal display when I type in an extension number:

You’ll see the normalised number – notice how 8622 actually maps to a 5831 number – but it would be useful to see the extension, like this:

With this set, it displays the extension as well – of course you have to have it normalised like that in your dial-plan and your address book rules for it to appear as above.

Anyway, how do we achieve this? Well, it’s pretty easy. You can do it in a client policy, like this:

$x = New-CsClientPolicyEntry -Name “ShowExtensionInFormattedDisplayString” -Value “True”

$y = Get-CsClientPolicy -Identity Global

$y.PolicyEntry.Add($x)

Set-CsClientPolicy -Instance $y

The above puts it in the Global policy, but you could if you wanted create a new one, and assign that. See here on the processes for adding options to client policies:

New-CsClientPolicyEntry

WAIT! What if I want to remove it? Well, again it’s pretty easy.

$y = Get-CsClientPolicy -Identity global

$y.PolicyEntry.RemoveAt(0)

Set-CsClientPolicy -Instance $y 

The above assume it’s the first policy entry – you’ll need to update it to match the actual entry if you have multiple ones. Note you can clear all of them too using this command:

Set-CsClientPolicy -Identity global -PolicyEntry $Null

Fairly simple stuff. This capability was first introduced back with Lync 2010 – see here for info:

An update is available to display the extension number of non-US telephone numbers in contact cards in Lync 2010