By Simon Woodhead
With the new stack largely behind us, we’ve got a new feature for you.
This is in early alpha which means we will break it, there are bugs, but we’d really appreciate you playing with it and giving us feedback.
So, currently, for outbound traffic we give you distinct hostnames for each of our availability zones, and do the same for our Registration Proxies. We routinely modify DNS to move traffic around maintenance etc. but, as was highlighted with our new stack migration, some customers either ignore the hostnames and force traffic to specific IP addresses, or have useragents which cache DNS until restarted. Neither is desirable.
Furthermore, the decision as to which availability zone to send traffic to is left in the hands of either us (for global DNS names) or you, for the regional availability zone specific names. This selection doesn’t always follow sound logic and we’ve had instances of customers forcing traffic across one availability zone to reach another that, presumably, they assume will be quieter.
In an ideal world, therefore, we want one global hostname, mapped to a single IP address that never needs to change – so it doesn’t matter if people force the use of the IP address. That address should exist in every availability zone, and traffic should hit the one that is closest. That decision should be dynamic and seamlessly handle availability zones, servers, or services coming and going. It should also be dynamic such that as network conditions change, or as nomadic users step off planes, they hit the best (closest available) node for service at that time. As a focal point for attacks, it should also be very resistant, and leverage the network to spread load across many many instances, rather than the typical single ‘active’ node. Naturally, because we vehemently disagree with the suggestion that ‘encryption is pointless‘, it should fully support encryption of signalling and not get in the way of media encryption.
We believe this is what we’ve put into alpha release today! It builds on the massive work we’ve put into anycast in 2017 and have presented on throughout the year. As we mentioned in those talks, we started from the inside out with this and are now ready to leverage it at the SIP layer.
The host any.simwood.com can be used in place of outbound proxies for normal IP authenticated or credential based trunks, or indeed as an endpoint to REGISTER to for our Registration Proxy. It supports udp/5060, tcp/5060, and tls/5061 although we continue to strongly recommend TCP or TLS, and do not support UDP for SIP Registration.
We’re very excited to hear your feedback.
