Update: After allocating the new IP addresses I could not get the server on
188.8.131.52 to consistently acquire a database connection. I tried rebooting it several times, swapping the IP address to the alternative server, waiting for over an hour but all to no avail. In the end I ditched the IP address and allocated a new one which is so far working fine. Just another quirk of EC2 I guess. The IP addresses for sip1 and sip2 shown below have changed from what was originally posted.
Thirty minutes ago I attempted the straight forward operation of swapping the IP addresses on sip1 and sip2 so as to do an operating system and software upgrade on sip1 (sip1 is by far the busier of the two servers). Unfortunately I clicked the “Release IP address” button instead of the “Disassociate IP address” button in the ElasticFox tool and I lost the two static IP addresses that the sip1 and sip2 servers were using. I was instictively staying away from the button with the big red X on it but in this case that was the correct button. The consequence of the malfunction by me is that the IP addresses of sip1 and sip2 will now be different. I’ve updated DNS and the since the A and SRV records were all set with timeouts of 1 hour they should have already started to propagate. At 1000, about half the normal number, device registrations are back and calls are going through.
The new IP addresses for anyone that needs to hard code them into their ATA or provider settings are:
sip.sipsorcery.com and sipsorcery.com both resolve to sip1.