3/8/2013 UPDATE: I’ve since used these instructions to integrate with Lync 2013 and have had the same success with using Asterisk as my PTSN gateway. I’ve added some notes in the Trunks section based on my experience!
Back in January I had a client look to use a hosted PBX solution for their office, with a mix of desk and soft phones, but didn’t want to make the full on investment with Lync (boo). So as a compromise they went with an Asterisk box plus some inexpensive Cisco SPA phones. Without diverging too much off course, I went through a few iterations with SIP providers and eventually came to the realization that using a Lync certified partner AND have a diverse product offering were not two things that could exist in the SMB IT universe.
So I decided to setup a front end Asterisk server as the “PTSN” gateway, housing the SIP trunks and the extensions for the client, and thought to myself “Why can’t I just as easily tie Lync into this system?” After DAYS of research plus trial & error, I wanted to share my pain points to help out the IT community.
A little on my deployment:
I’m the latest version of FreePBX for my Asterisk box, and Lync Server 2010 with CU6 for my Enterprise voice deployment. I’ve also an Exchange 2010 SP1 CU6 Unified Messaging box for voicemail on the Lync side.
With everything setup and rolling on the FreePBX side, and the ability to call between Lync clients, my next step was to integrate the two.
I enabled Enterprise Voice capabilities on my Front End server, and made sure to change the listening port to 5060 (because this is what FreePBX listens on).
I also added a Mediation server, using the IP address of the Asterisk Box.
Once that was done, I published my topology and that was it from the Lync infrastructure side.
Over on the FreePBX side, I create a new SIP TRUNK called Lync and all I needed to complete was the following OUTGOING SETTINGS > PEER details, where the host is the IP of my Lync box
and the fromdomain is the IP of the IP of my FreePBX box (this is important!) UPDATE: I’ve since discovered that the fromdomain doesn’t effect the traffic one way or another!!
One additional pointer: the context of from-internal is very important for routing calls from Lync through the Asterisk box and outbound through the SIP trunks. Anything else will still allow internal extension dialing, but fail elsewhere.
Be sure to leave the INCOMING SETTINGS > Peer Details blank
Now I already have all my Incoming Routes setup (my DIDs) I’m ready to setup my Outgoing Routes. The first is going to be called LYNC, and all this has is a dial pattern for FreePBX to have the ability to call 4 digit extensions between the two systems.
Next, in the existing Outgoing Route, which I have called Outgoing, we have all of the local exchanges here in the Twin Cities, another to account for everything else, and finally, MOST IMPORTANTLY, the dial pattern to account for E.164 dialing within Lync.
If you don’t add this, the calls WILL go between the two systems and their internal extensions, but will never make it to the public PTSN. You’ll see something like this in the Asterisk debug logs:
[2012-07-11 11:34:36] NOTICE[-1] chan_sip.c: Call from ‘Lync’ (10.20.110.6:60594) to extension ‘+19521234567’ rejected because extension not found in context ‘from-internal’.
At this point the trunk configuration is changed, however we need to add 2 “Other SIP Settings” on the Asterisk server, because by default it doesn’t listen properly on port 5060, and will prevent communication issues between the Lync & FreePBX servers:
After you make this change, it’s best to perform a restart of the PBX server for them to take effect.
Now at this point, with the FreePBX server configuration completed, we would go back into our Inbound Routes (DIDs) in FreePBX and change the Trunk Destination to the Lync trunk.
But now the FreePBX side is only half the battle. On the Lync side, we need to make sure we create our users having the same phone number we are forwarding from the SIP trunk, but of course in E.164 format (+1xxxxxxxxxx). Also, make sure to enable Unified Messaging on the Exchange server for the users when completed.
The most challenging part of the integration by far was the Voice Routing and Normalization. Apart from the +1NXXNXXNXXX pattern on the FreePBX side, getting the correct normalization rules to allow calls FROM Lync and TO FreePBX, plus vice versa, all boils down to normalization. But luckily when it’s all said it done, there are really only 5 rules:
I added in a normalization rule for communication internally from the FreePBX server using 4 digit extensions over the the Lync server. The other key on this was to specify it as an internal extension:
Once these are setup and ready, we modify the Global Voice Policy to add a PTSN Usage that is essentially a Wildcard for any numbers, to pass them to the Mediation server. This then lets the FreePBX server do the translation.
You can name your Voice Route anything you’d like; I just named my SIP Trunk so it would stand out for the sake of recognizing what I had added.
Finally, perform a Commit All to the configuration in Lync, and you’re ready to go!
I use the 3CX Softphone to connect to the FreePBX server, and with the Lync client fired up I call the internal extension – volia!
And then vice versa from Lync back over toFreePBX
The only outstanding issue I’ve run across with this deployment is using the call forwarding and corresponding Lync Mobility features. I’m digging into them and hope to be back soon with a solution.