IP Office is very strong in building a network of multiple systems that feels like a single PBX for the end user. Users can call each other between sites as if they are local. You can build hunt groups with members from different sites and users can have remote users on their phone’s buttons and many more. Technically you just have to build a SCN (Small Community Network) connection between the systems and you are done. The systems exchange all relevant data of the remote systems (like users, hunt groups) and know the best way to reach a remote user.
The challenge
Most times each site has it’s own PSTN connection but internal calls are handled through the SCN connection. But what happens if the connection between sites is lost? That can happen easily if the VPN fails.
Even if it is not officially documented, Avaya built in a fallback mechanism that can help you to manage such situations. There you can define what should be dialed by IPO over PSTN to reach a user if the SCN trunk is down.
The implementation
The implementation of that fallback feature is pretty easy. You just have to know how it works. As mentioned above you need to define for each user or for ranges of users how to reach them over PSTN. Practically you need some kind of a table that brings the user’s internal number with the user’s PSTN number together.
That can be easily done by creating a special ARS table. That ARS table has to have the name **NET** to act as a SCN fallback table. IPO knows about the users and groups within it’s network so that you can call them like a local user. If a remote user is not reachable caused by a broken SCN link, IPO searches for a **NET** ARS table and checks for informations how to reach users over a PSTN connection. That ARS form can be seen as a table that defines the public reachable number for each user or for ranges of users.
In the following screenshot you can see that users in the range from 300 up to 399 as well as user 193 are usually reached vie the SCN trunk. In case of a failure of that trunk we can reach user 193 by dialing 7*****193 on the PSTN line (line group 0 in that example). For the 3xx range we have another ARS short code to dial 7*****3N over PSTN. The ‘Si***’ part following the dialed number is to define what number to use as sender ID.
ARS form **NET** that links remote user’s internal numbers with the PSTN number to reach them alternatively.
Conclusion
Using already available IP connections to route phone calls between different sites can save money and brings usability enhancement. But customers don’t want their users to keep an eye one the connection to determine if they have to call remote users internally or through the PSTN connection. If an IP connection is unstable this will lead into a situation where users tend to dial always over PSTN because in their mind that is the more trustworthy connection. And the potential money saving is gone.
As you can see with a single ARS table you can ensure that remote users can be reached by dialing their internal number even if the SCN link is temporary down. That will lead into a higher acceptance and easier usage. Nevertheless IPO will always try to call using the SCN trunk with all it’s benefits and will use the PSTN only as fallback option.
I hope that helps to build Small Community Networks with the extra option to reach remote users even if the IP link between systems is down. Customers like the additional security. If you have any comments don’t hesitate to leave them here. If you like that content share this page with others you think they like my ideas.
If you need further help with IP Office you can contact me through my main website: https://www.fwilke.com/home
Do you want to get information about new posts? Subscribe to my Newsletter