Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In this guide we will be using two PBXact v14 appliances along with Zulu 3 as the endpoint but this could also be applied to other SIP servers such as SBCs or other endpoints such as SIP softphones lacking a the possibility of defining a Secondary/Backup SIP server.

Pre-Requisites

Limitations

  • Only one Health Checker, that is, AWS Route 53 method for determining server availability, can be setup at a time (ie. only one, the AMI port 5038 or the Zulu port 8002, could be monitored to determine if the PBX service is available or not). This brings the following possible complications:

    • When Asterisk process (tcp 5038) is selected to be monitored on AWS Route 53 for checking PBX availability (recommended as asterisk service tends to fail more commonly than zulu server)
      • If only Asterisk fails (tcp 5038), but not Zulu (tcp 8002), AWS will switch the IP address the FQDN resolves to. Zulu will not be able to automatically failover though as it does not detect any problem registering with the current server. Restarting the Zulu application will make the failover take place
      • If only Zulu fails (tcp 8002), but not Asterisk (tcp 5038), AWS will NOT switch the IP address the FQDN resolves to. Zulu will get disconnected as expected. Troubleshooting would be needed to determine the cause for Zulu server failing and bringing it back up

    • When Zulu process (tcp 8002) is selected to be monitored on AWS Route 53 for checking PBX availability
      • If only Asterisk fails (tcp 5038), but not Zulu (tcp 8002), AWS will NOT switch the IP address the FQDN resolves to. Zulu will not be able to make or receive calls as expected. Troubleshooting would be needed to determine the cause for Asterisk failing and bringing it back up
      • If only Zulu fails (tcp 8002), but not Asterisk (tcp 5038), AWS will switch the IP address the FQDN resolves to. Zulu will automatically failover (Note: restarting the Zulu application may still be needed for correctly authenticating on the new server)

  • Zulu 3 has (currently) no possibility for defining the value for its SIP Registration Expiry timer, it is permanently set to 600 seconds (10 minutes). This makes it necessary to restart the application once the main server has come back online in order to failover back to it

Step-by-step guide

Configurations on Amazon AWS Route 53:

...

  1. Open the firewall for the specific IP addresses Amazon AWS Route 53 uses for the Health checking of the SIP server. In a PBXact server it can be done by executing the following command in the Linux console as root user:

    fwconsole firewall add trusted 15.177.0.0/18 54.183.255.128/26 54.228.16.0/26 54.232.40.64/26 54.241.32.64/26 54.243.31.192/26 54.244.52.192/26 54.245.168.0/26 54.248.220.0/26 54.250.253.192/26 54.251.31.128/26 54.252.79.128/26 54.252.254.192/26 54.255.254.192/26 107.23.255.0/26 176.34.159.192/26 177.71.207.128/26

    Info

    For the current list of IP addresses Amazon AWS Route 53 uses for its Health checks search its ip-ranges.json file for "ROUTE53_HEALTHCHECKS" - Ref. https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html


  2. fwconsole firewall stop

  3. fwconsole firewall start



Conclusion

The configurations have been completed. For testing the failover you can easily force the main SIP server to go down. In a PBXact server, for example, this can be done by executing the following command in the Linux console as root user:

...

Amazon AWS Route 53 will automatically revert the IP address the Domain (FQDN) resolves to back to the main SIP server as soon as it detects, thanks to its Health check, that the main server has come back online again.


 


Warm Spare