One of Lync' Server 2013’s strengths is its ability to interoperate with everything else. Whilst I’m sure that the more fervent marketers would have preferred all MS clients to rip out and replace their PBXs with Lync, that was never a very realistic early goal. If for no other reason than many companies have significant investment tied up in the status quo PBX – chucking that in the skip is a difficult thing to contemplate, especially in the current economic client.
Instead, Microsoft has wisely pursued an approach of interoperation with things like the Mediation Server, SIP trunks and PBX interoperation. That enables the organisation to adopt Lync without initially taking the Enterprise Voice parts. When it becomes economically relevant to consider upgrading their telephony, THEN they can move to Enterprise Voice. It’s a very sensible strategy, IMHO, and I’m seeing it a lot in my travels.
Now Lync is a complex product, as are the PBXs and other products Lync talk to. In theory, all that’s needed is a Gateway to convert SIP to trunk signaling, ensuring you’re using the proper codecs, and a bit of configuration magic and all is well. In many cases that’s true. But it helps to know what you are doing.
One way Microsoft is helping is producing integration guides, like the most recent one: Lync 2013 and Avaya Aura 6.1 Integration Guide. Written by Tekvizion PVS this guide shows you how to configure interoperability between the two product sets.
On the Avaya side, the Guide is based on the integrating of a CS1000 (v 7.50), an Aura Session Manager (v6.1.2.0.612004), and Lync 2013 RTM (I assume that there;s no issue with the CUs – but the guide is based on RTM). There’s a bit more configuration to do on the Avaya side, which is probably appropriate as it’s doing the PBX interconnection and has to route both externally and to any existing internal PBX lines/trunks.
On the Lync side, it’s fairly painless. You start by creating a new IP/PSTN using Topology Builder. You define the root trunk specifying the IP address of the Session Manager box and and the associated Lync Mediation server and then publish the topology. You then need to configure the trunk. You also probably need to adjust your voice policies, PSTN Usage Records and your dial plan to accommodate the Avaya solution in terms of who can use the switch, and your dialing rules that accommodate the Avaya switch. This may mean new policies and PURs or just some editing of existing ones depending on your topology.
You configuring Lync Server partly from the Lync Control Panel and for some components you use PowerShell (e.g.: e.g. specifying RTCP, Session Timer and Encryption level parameters). Personally, I’d prefer to see the entire configuration process done in PowerShell – but I would say that. What I find so wonderful about PowerShell in this environment – you can define the configuration by writing the PowerShell script. From then on you can refer to it to see what you configured!
A couple of things, though, that I noticed in reading the guide. First, the guide wants the communication between the Mediation server and the Session Manager box to be over port 5060 – or SIP over TCP. That means the physical link between these two systems is a potential security risk. To minimize the risk, you could connect the two physical devices just using a crossover patch panel if that is feasible. It’s a risk to recognise and mitigate as part of your configuration.
Secondly, it seems like media bypass is not supported – you are instructed to turn it off. That means that for all calls, the call data will transit the mediation server. For this reason, you need to consider carefully how or whether to co-locate the mediation server with the Front End solutions. With more highly utilised mediation servers, you also may wish to re-evaluate whether to have the be virtual or physical mediation servers. It’s another aspect to consider when doing your initial planning.
