//just saw RentPBX reply, sorry if I sound like a parrot.
There are valid points to both sides.
Chris, some of the potential problems with your suggestion is that although it works fine and can be an excellent way to do it.
It's completely customized and dependent on a proprietary service offered by dns made easy.
Their monitoring agent is not a SIP agent. and will only failover when detecting the failure scenario that dns made easy coded into their tool(with the customization they allow). a kind of nmap+pinger sorta thing.
If the machine is up and everything is dandy except that asterisk is somehow borked. DNS made easy will not trigger the failover.
Also, although rare, it appear you never faced recursive DNS server that ignore low ttl and cache records for longer than the ttl specifies. This can be a pain if you have remote clients and whatnot since you don't control the DNS server that will be serving your potentially unfailed over records. Rare, but possible in the wild.
All that is easy to work around or simply ignore if you don't face those problems. You're solution is a good way to do that with the help of a pretty cheap dns service.
It won't detect all failure scenario and might require manual intervention to trigger the failover if the dns made easy agent consider it's up while the phone are seemingly not working...
The plus side of DNS SRV is that they are the standard for doing stuff like that. It's why they exist. If using software that support them(big if in some cases, you right, but some are in this scenario) correctly the solution is cleaner and more standard.
That's what RentPBX means by the sip agent ability to detect failure on its on terms. DNS made easy could consider your server up while asterisk is completely hanged for 24 hours.
A proper DNS SRV supporting sip endpoint, will failover, it's not pinging or checking sockets...
So there is potential in both solutions, it depends.
Anyway, let's be clear, VOIP is a pretty hard thing to failover cleanly and automatically...
What if sound is choppy or a bit robotic between my pbx and the provider's POP, or between a remote endpoint(just this one) and the PBX.
You'll get crappy sound all day long unless you have a method to manually failover something to something else.
Either the phone register on another PBX or your pbx needs to start receiving and sending calls to a different POP or different provider entirely.
There is no fully automatic solution to plenty of VOIP failover problems unless you do a lot of specialized coding around asterisk/freeswitch and possibly the endpoint itself...
So I can see why Chris is defending it's setup, it's a good way to do it and it has a somehow automatic feel to it, for some failure scenarios, and it's easy to manually failover if it's doesn't do it.
But in both scenario
there is plenty of room for problems that won't trigger failover and where even a manual failover, won't do a thing to fix the issue impacting quality.