:::: MENU ::::
Posts tagged with: IPOffice

Testing Lync Failover to Backup Registrar “Got Ya”

Project Scope
Preparing for Deployment – Research and Education and Pricing
Deployment of Standard Server & Director Role
Deployment of Edge and Reverse Proxy
Deployment of Lync Voice Capabilities
Configuring Lync PSTN Calling thru Avaya IPOffice
Configure Lync 4 Digit Extension Dialing without DIDs
Configure Asterisk as a SIP Proxy for Avaya IPO and and Lync
Deployment of Lync Client to users
Testing Configuration of Backup Registrar

Continuing the series in our Lync Deployment.  As we are approaching the date that we will completely cut over all users to lync we wanted to build in some redundancy to our deployment. 

We have done this by licensing a second standard server and configuring it in the topology as a backup registrar.  This will allow us to have a fail over server to host all voice calls in the event of a failure to the primary standard edition server (PSE).  The Backup Standard Edition Server (BSE) will provide voice capabilities and limited IM capabilities in a production down situation of the PSE. 
Note: for calls to be made in a ‘failed over’ scenario backup calling routes will need to be configured for the BSE mediation role as discussed in a future post

So we have configured our backup in the topology (how to in a future post) and configured the failover routes so it is time to test the scenarios.  For our testing we want to confirm that the PSE can fail and we can still make calls to the PSTN and if the PSTN is not available make a call out the analog backup lines.

You will want to review the default setting in your topology to set it to the lowest value possible when testing otherwise this test could take 15-20 minutes depending upon your value selected to fail over to a backup registrar. 


Our test was to remove the NIC from the PSE, the Lync clients will disconnect, attempt to re-connect and after the specified time connect to the BSE as the fail over registrar and make calls via the PRI and Pots lines.

However after configuring a Backup Registrar Lync Clients wouldn’t login during a failed server.  The clients would drop the connection as expected but however, they wouldn’t login to the backup registrar with limited functionality as expected. 

Side note… Kudos to @DHannifin helping figure this one out…
check out our awesome buddy Dustin’s blog:
http://www.technotesblog.com/ for lots of Uber good Lync goodness.

Even after changing the fail over time to just 30 seconds, the phone handset endpoints would login and calls could be made, but the Lync client would fail to login.   After some digging in the trace logs we found client that wouldn’t connect that we were getting an unauthorized error because the newly added BSE server wasn’t in the user certificate issued by the server to the client so the Lync client didn’t trust the backup registrar.

The Lync Client uses a certificate for communications with the front end server.  This certificate is not updated very often, in fact the default value to when it will update is 8760 HOURS that’s 365 DAYS!  (A little longer than we wanted to wait for our testing…Winking smile)

You can use the PowerShell command: Get-CSWebServiceConfiguration
to review the current values of your setting for MaxValidityPeriodHours’


Since we didn’t have a year to wait, there are a couple solutions.
1. Change the default value by using the PowerShell command
Set-CSWebServiceConfiguration but this changes the cert settings for all clients and would require time for replication.
2. Delete the certificate on the machine that you are using for testing. This is a little more killing a fly with a sledge hammer, but for this testing appeared to be the best solution.

So in a testing scenario where you don’t want to change the re-issue certificate settings, on the machine you are using to test, simply launch an mmc window add the add-in for certificates and choose to manage users certificates.  Next browse to the personal certificates where you should find a certificate named the SIP URI of the user you are logged in as and it is issued by ‘Communications Server’. Delete the certificate and then restart your Lync Client (exit the application not just log off). 

Note: After deleting the cert, before you re-launch the Lync Client, you will need your primary front end server online so a new certificate can be issued to the client on the workstation.  Otherwise you still will not have valid certificate to connect and since the PSE is offline your client will try to connect to the BSE for which it still doesn’t have a valid cert.

After you re-connect to Lync to the PSE you can then power off the PSE (or remove the virtual nic from the virtual machine as we did.) You will notice the Lync client log off and after your Backup Registrar time out passes Lync will login to the Backup Registrar.  You will know this has happed when you see the Lync client display the red bar indicating limited functionality.

Lync Backup Registrar

If you have correctly configured a backup call route to your gateway, all voice calling will route out the gateway as if your Lync topology was operating normally.

Note: In an actual failover after you have configured all backup routes a call in progress should stay active even while the Lync Client is going thru its log off/log on process to connect to the backup registrar.  If you are in an active call during this fail over, your call should stay connected, BUT it will disconnect if you hit cancel on the Lync client during the reconnection process.

Configure Asterisk as a SIP Proxy for Avaya IPO & Lync

Project Scope
Preparing for Deployment – Research and Education and Pricing
Deployment of Standard Server & Director Role
Deployment of Edge and Reverse Proxy
Deployment of Lync Voice Capabilities
Configuring Lync PSTN Calling thru Avaya IPOffice
Configure Lync 4 Digit Extension Dialing without DIDs
Configure Asterisk as a SIP Proxy for Avaya IPO and and Lync
Deployment of Lync Client to users
Testing Configuration of Backup Registrar


This post is a continuation of a series of posts about Lync Deployment. The documentation portion of this project has gotten the back burner, and I need to say that a blogger I am not.. but picking up the documentation of this process is important.

This can be used as a resource to configure an Avaya IPOffice (IPO) 412 (software version 5.0) as a Gateway for a Lync deployment calling the PSTN, with AsteriskNOW as a SIP proxy to resolve disconnected calls when placed on hold or transferred, your mileage may vary. Calls are routed over a SIP Trunk (Session Initiation Protocol) configured between the IPO and Asterisk and Asterisk and the Lync Front End server.

Once we deployed the calling from the PSTN via a PRI from the IPOffice to a SIP connection to the Lync Mediation server we were able to make and receive calls from Lync endpoints, however we quickly noticed that when calls were put on hold or needing to be transferred to another extension the call was simply dropped.  It doesn’t matter if the call was being transferred to a Lync extension or an Avaya extension the call would drop.  The only option to “hold” a call was to mute the call.  If Hold was used the call would disconnect.

After a few days of tracking this down we were able to identify this was an issue that happened every time.  It wasn’t specific to a user or extension.  In fact the Avaya white paper noted this as a known issue.

Avaya PSTN Config

The issue is documented on the final page: https://devconnect.avaya.com/public/download/interop/OCSR2-IPO-PSTN.pdf

The document notes that calls cannot be placed on mute, nor does the PSTN caller ID pass thru to Lync, these notes however that was not our experience.  Mute and Caller ID worked fine on inbound calls.

We tried several different solutions to resolve this issue.  Our first attempt was routing all calls thru an inGate SIParator.  This is basically a SIP proxy device.  We happen to have one laying around from some testing with a SIP dial tone provider.  This device had worked well with the IPO connecting to SIP Trunks that required authentication with a different authentication handshake than the standard Avaya methods.  However the SIParator did allow to proxy the Avaya to Lync SIP trunk, but didn’t resolve the disconnects when holding or transferring calls.

Next we tried to use a SnomOne software PBX, this had some promise, after configuring the call to forward all calls to the Avaya or Lync (which was a hassle) we found that this resulted in calls connecting but the caller not hearing any of the conversation, or the call would just stop passing audio although it remained connected.  We also found that the SnomOne would keep terminated calls still active and you would have to reset the sessions manually.

Finally we landed on an asterisk installation installed on a virtual machine.  We installed Asterisk now (without the web interface) for simplicity.  Once you configure the two sip trunks (one for Avaya and one for Lync) and build the dial plan to forward all calls from Lync to Avaya and all calls from Avaya to Lync the configuration was basically complete.

Much Credit must go to my great Church IT RoundTable peer Dave Mast (@DaveMast) for his Asterisk Programming help! Kuddos to Dave!

Below are the steps to configure the Avaya and Lync to communicate via an Asterisk Proxy.

Install Asterisk on a machine, (in our case a new VM) and note the IP Address you give the server.  Next configure a new Avaya SIP Trunk and ARS Table. The same steps as noted here, except you need to enter the information of your Asterisk server in step 2 as the ITSP IP Field.

After completing steps 1,2,3 and 4. Complete Step 5 to prepare an incoming call route from Asterisk to the IPO.

Step 6 is basically the same and we repurposed the old ARS table that we created but changed the short codes and features a little. 
Ars table

Note in step 9 if you have extensions on both IPO and Lync you can’t use variables in your short codes.  This remains true.

After step 10 things change a little so I will document that here.  The information may look very similar to the previous instructions with SIP for IPO and Lync with out a proxy but they are a little different.

Because of how you have to pass calls from Avaya to Asterisk you will need to configure you rARS table a little differently.  Step 10 walks you thru a extension with a DID, that in fact is no different.  But Step 11 has changed. I have quoted the information that hasn’t changed and added what needs to be adjusted for the dialing plan to work with Asterisk.

11. Configure routing for For Lync Extensions without DIDs (as documented here).

An ARS entry will have to be created for each Extension since the IPO cannot use variables in the E.164 formatting of the outbound call and Lync requires the call to come in in the +11235556500;ext=4175 format.

The Asterisk can’t pass the formatting with “;” so we will pass just the 4 digit extension from IPO to Asterisk, and our 4 digit dial plan dialing rule that translates calls TO those extensions from a lync endpoint into +11235556500;ext=4175 format will cause the call to route to the extension when it comes into Lync from Asterisk.

This example extensions 4150-4175 don’t have DIDs but were valid Lync extensions, in order for IPO extensions to call extensions 4150-4175 a short code would be required for 41xx Pointing to the the SIP-Lync ARS Table. (Assuming no other extensions in the 4100 range are homed on the IPO). NoDIDShortCode
Then entries for each extension would need to be added to the ARS table.
Code: 41XX, Feature: Dial (if the IPO has any restricted calls to outside use Dial Emergency)
Telephone Number: +1235556500”ext=4150@”
Telephone Number: 41N”@” (the “”s are required to tell IPO that nothing contained in this part of the string is a variable. All extensions in this range can use this variable.

4 digit short code

Next you will need to configure Lync to see the Asterisk as a gateway.

1. Configure Lync Call routing to use the Asterisk as a Gateway. This assumes you have enabled users for enterprise voice which is a fairly well documented process: http://technet.microsoft.com/en-us/library/gg413011.aspx
After users are enabled, go to the Topology builder and browse the Standard Server. Check the box for Enterprise Voice


Edit the properties and go to the Mediation Server. Enable Collocated Mediation Server. Define your Listening Ports and click new gateway enter the IP address of the Asterisk and the Port that it is listening for SIP traffic on.


Next associate the Gateway with the mediation server


Publish the Topology.

2. Configure Dial Plan and Trunk. Open Lync Control Panel and go to Voice Routing then Trunk configuration open the newly added Gateway and change the Encryption support level to Optional, Uncheck Media Bypass, Uncheck Centralized Media Processing and Uncheck Enable Refer Support.


3. Add a translation rule to call 4 digit extensions on the IPO via the Asterisk. This allows a normalized call from the Lync server to pass just 4 digits to the IPO so it correctly routes to the extension on the IPO.
Starting Digits: +12355565
Length: Exactly 12
Digits to remove: 8
This rule tells the Lync server to simply pass 65xx to the IPO.


You will also need to create a translation rule to pass all digits without the +
Starting Digits: +
Length: Exactly 12
Digits to remove: 0
This rule tells the Lync server to pass 11 digits to the Asterisk.

4. Create a Call Route. Select New Route and name it and add a description. Leave the Pattern to match the default “*” which matches all calls. VoiceRoute-1

5. Scrolling down select Add for Associated Gateways and select the PSTN Gateway. Do not yet associate a PSTN Usage. But confirm the Gateway is added.


6. Create a Site Voice Policy Choose new and select the site you want to add a voice policy for. Add a Description and enable all appropriate features. Then New.


Associate the route just created in step 6 by hitting select

Associate PSTN Route

choose the route.

Select PSTN Route

Go back to Routes and edit the Asterisk PSTN route and scroll to the bottom and Associate the PSTN Usage created.


Commit all Changes.

Configure the Asterisk Box

Finally you need to configure the Asterisk.

  1.   First Configure the SIP Trunks
    Login as root to the asterisk server and enter: nano –w /etc/asterisk/sip.conf
    Your configuration should be as follows:

    host= (where is the ip address of your lync front end server)
    context=name-of-lync-context (use what ever name you want)

    host= (where is the ip address of your ayava IPO)
    context=name-of-avaya-context (use what ever name you want)
    Hit Ctrl-X and choose to save


  2.   Next Define your Dial plan to forward all calls.
    enter nano –w /etc/asterisk/extensions.conf
    Your configuration should be as follows:
    exten => _+1xxxxxxxxxx,1,Dial (SIP/Avaya_Trunk_Name/${EXTEN},45)
    exten => _+12xx,1,Dial (SIP/Avaya_Trunk_Name/${EXTEN},45)
    exten => _1xxxxxxxxxx,n,Hangup()

    Line 1 passes PSTN calls from lync to the PSTN
    Line 2 passes 4 diget extensions dialed from the Lync to IPO

    exten => _+1xxxxxxxxxx,1,Dial (SIP/Lync_Trunk_Name/${EXTEN},30)
    exten => _+41xx,1,Dial (SIP/Lync_Trunk_Name/${EXTEN},30)
    exten => _1xxxxxxxxxx,n,Hangup()

    Line 1 passes PSTN calls and all Lync Extensions WITH DID to Lync
    Line 2 passes 4 digit extensions dialed from the IPO that don’t have a DID.

    Exit and Save the configuration

    asterisk dialplan

    One item to note, the value of 45 is the seconds the phone rings before disconnecting the call.  We had to change the default of 30 to 45 because when someone would call a cell phone FROM Lync via the IPO PRI the call sometimes wasn’t getting to the cell phone voicemail before the 30 seconds and would drop the call before the Lync caller could leave a voicemail for the person they were calling.  After adjusting this value above 30 these dropped calls stopped happening.

  3. Reload the Configurations
    Enter: asterisk –r
    Enter: reload

    After the config reloads enter: /sip Show peers
    your status for both SIP trunks should show “OK”

    You are new ready to make calls from lync to the PSTN and place calls on hold.

Avaya IP Office 412 & 5610IP & Sonicwall VPN

Recently several new initiatives have caused us to look into extending our Phone system beyond the physical location of our main campus.  We have an Avaya IP Office 412 with 150+ digital extensions.  As part of the IPO you can do VOIP extensions but we haven’t had a large need to deploy those since our building was already wired for a phone and data network separately (Major PROS & CONS to this but not in this post). 

We do have however a couple handsets in locations where we can’t get a pair of copper for the digital phones so we have  a couple VOIP extensions on campus.  Those have worked great, plug the phone into the network, configure the IP and the VLan and your making calls.  So it should be that easy over our VPN right?  Wrong. 

After several hours of searching to figure out the issue we learned it was both a IPO Issue as well as a configuration issue in the Sonicwall Firewalls.  Since there was little documentation about this specific combo I have documented it here as well as the nuggets of info we learned along the way.

Hardware Used:
- IPOffice 412
- Avaya 5610sw IP-Handset
- Sonicwall TZ100 at remote location and Sonicwall EClass 5500 on main campus.


- Configure a new IP Extension on the IPO, Enter Only the Extension ID and Base Extension
- Configure the User for the Extension and Program Buttons Etc.
- Create an Incoming call route for the DID
- Connect the 5610 to the local network to make sure the phone is working locally. 
- Boot From DCHP, Enter IPO IP address (Phone Server) and Enter Voicemail Server IP (FIle Server)
- After the phone talks to the IPO it updates Firmware updates and the the phone is functional

At this point all was well and we were able to make and receive calls from the IP handset and it was time to take the phone to the remote site.  The remote site is where we started having connectivity issues and the phone wouldn’t boot completely.

-Plug in the phone and choose DHCP and it fails to connect to the server.  Do  a phone reset to clear out all networking gremlins from local network settings: Press Hold then 25327#
-Phone reboots and grabs DHCP address but cannot talk to the TFTP server.
Note: Workstation running the IPO Manager software runs a TFTP server when the application is open but not editing a config file.  If Manager isn’t running IP Phones will not update.

In the troubleshooting we could ping any device on the core network from the VPN except the IPO.  You could ping the Voicemail Server but no response from the IPO.  This was because the IPO requires you to  manually add an IP route for each subnet that is not the subnet of the IPO’s LAN1 Interface.

Some discussion forums noted that you would have to have a license for VPN or Remote IP Handsets but that is not the case.
To Configure the IP Route in the IPO:
- Open the IPO Config Manager and navigate in the tree to: IP Route
- Right Click and Choose New.
- In the new Route Config enter the IP Address of the Remote Router, IP Mask of the Remote Location
- The Gateway IP address should be the LOCAL IP of the Gateway on the Local network
  (Don’t enter the Gateway IP that you entered above in the IP Phone)
Choose the Destination of LAN1
- Save and Merge the Config. (Values shown have been modified and will not work with live config)

After this we should have seen the IP Handset boot, talk to the TFTP server and then work…. but that wasn’t the case.  When the phone would boot it would not show up as an extension in the IPO System Status nor would it check in with the TFTP server.  It would however appear to have booted and have a base extension without any call appearances.  Trying to use the phone resulted in a bunch of beeps.

After we were finally ready with the IPO configuration it now appeared something was blocking traffic over the VPN link from the remote location to the main campus. 

A call to Sonicwall reveled that in the latest firmware 5.5.x there are default settings enabled that should not be enabled to allow H.323 packets to travel from remote to local sites over VPN.  These settings should be enabled if you are NATing VOIP traffic via the WAN but not enabled if your VOIP traffic is traversing via VPN.
(Leads me to ask the question, can you not have a combination of VOIP Over VPN and VOIP via NAT, but that question can remain unanswered since it doesn’t impact us).
To disable these settings in the Sonicwall Admin interface go to VOIP and the ALL of the following should all be DISABLED on BOTH routers (Local and Remote).
- Enable Consistent NAT
- Enable SIP Transforms
- Enable H.323
It is important to note these setting changes require a reboot of both routers to take effect.

After a reboot of both routers and a reboot of the handset it registers with IPO as an extension and calls can be made and received.

It is important to note, this VOIP extension is not in the same physical location and it is the PBX operators responsibility to notify your dial tone provider of the physical location of that handset for E911 (PS/ALI Compliance).

Avaya IPOffice

Avaya Logo

If you are using an Avaya IPOffice PBX and are planning to upgrade to version 4.2.14 or higher and use a PRI configuring ‘NI2’ (National) calling you might want to be aware of this Technical Tip from Avaya’s Site.

In this release of the software, without the mentioned private build, all outbound calling is rejected by the PRI provider because the PBX is sending calls in the wrong format.

From Avaya Enterprise Tools Knowledge base:

This Technical Tip is to advise customers of a potential issue with T1/PRI lines configured for NI2 that may occur on upgrades or new installations with IP Office releases 4.1(15) and 4.2(4).

It has been observed that T1/PRI line configurations may not accept a called party type set to “National Number”. Certain NI2 line configurations are set to accept only called party type “Unknown Numbering Plan". The network provider may not process calls with the "National Number" format, rejecting the call setup as an invalid number format. This results in the inability to initiate outbound calls. 

Avaya has produced private build 4.2(49601) to resolve the issue by providing the ability to adjust the called party type to "Unknown Numbering Plan". After installation of the private build you must activate the function by adding the following string into the NoUser Source Numbers tab and then merging the change into the configuration: NI2_CALLED_PARTY_TYPE=UNKNOWN

Avaya IPOffice 4.2.14