reply to MartinM
Re: [Voip.ms] Survey / Feedback on restructuring Geo Locations. Thanks for the opportunity to comment on your plans. Here are some random thoughts to add to the mix from a long-time customer and forum lurker.
Consider having exactly two carefully chosen POPs. Expose them with separate names in DNS at first for simplicity, but prepare for the time when you can move to one name and control their use via DNS.
* More POPs means more to manage and keep in sync. One is "easy", two is usually "hard", but anything more than two is usually "much harder". Two POPs (each provisioned to handle your entire load) gives you site redundancy, is simpler to manage, and, importantly, is easier to get exactly right.
* Don't sweat the geographic diversity issue too much. Much more important is basic datacenter reliability and quality/diversity of connectivity. And don't rule out Las Vegas as a candidate, with its low earthquake and weather vulnerability, plentiful power, and great connectivity.
* SRV records are great in principle, but we've all learned recently that real-world client support for them is spotty at best, and incorrect at worst. Good old-fashioned round-robin A records with shortish TTLs are almost as good in principle, and often better in real-world practice.
* If you do use SRV records (as well as A records), don't make the mistake of returning more than will fit in an untruncated UDP response, even though doing so is perfectly "correct". Too many client resolvers (incorrectly) don't retry over TCP, and too many client firewalls (incorrectly) pass DNS requests only via UDP. If you absolutely need lots of hostnames, then define multiple A records per hostname, or use shorter hostnames (since SRV record hostnames "MUST NOT" be compressed), or something.
* Set as a longer-term goal making POP choice functionally irrelevant by syncing voicemail between the POPs, decoupling DID routing from user agent registration (like Anveo's Geo POPs, I think, but chosen and controlled by you), and much more that I'm sure I'm missing.
* Eventually, go further still by using a single DNS proxy name, and respond with the SRV or A records you want to based on load, server status, geographic estimate of client location, or whatever else you choose. Take this out of the hands of your customers. Some will complain that they want to choose their POP based on the quality of their routes to and from a particular POP. Some of this can be mitigated by your datacenter choices and the diversity and quality of their connectivity. It's not a perfect solution, but you need to control your service, and you need to eliminate your customers' need to fiddle with their endpoint and fiddle with your user portal to perform POP failover. I know you already do some of this when you want to direct customers away from a troubled POP, but you need to solve the resulting DID routing and voicemail issues, and you can go further and really control your network yourself, and do so better than most of your customers can.