By Simon Woodhead
We’re delighted to announce our new stack is now available in open beta.
If you’re the kind of person who just wants to get stuck in, the links (password protected) you’ll need are:
Outbound SIP interop
Inbound SIP interop
Registration proxy
Configuring Opus
Whilst we refer to this as the ‘new stack’ it is important to point out that not a huge amount has changed in SIP terms. Yes, we’re using the latest and greatest versions of every component, and yes we’ve added in some new whizzbang features such as Opus and better encryption, but awesome as they are they’re not really the big deal here.
This is actually a completely new platform, from the ground up. We’ve mentioned before about our network upgrade, and this new platform leverages that. We’ve discussed improved networking technologies such as anycast and this platform makes use of those to the max. If you happened to miss any of those talks, they’re at the end of this post.
So, brand new network (this stack is connected only to the new network), brand new hardware (no compromising availability of the old stack with redeployment), and brand new technology on top. That is the real ‘new’ here.
Previously we ran all media processing servers on bare-metal but everything else (including signalling proxies etc.) were virtualised on vSphere. For this new platform, the whole lot is containerised. We discuss that in the videos below, but suffice to say there has been an awful lot of R&D and many iterations of the environment throughout the last year to get where we are. This has been the prime reason for this all taking so long. We have a full pipeline of further changes but we’re finally happy with where we are now.
Whilst every micro-service involved is now containerised, and thus benefitting from bare-metal performance, we’ve maintained our abstraction of media and compute. So the many containers that handle RTP are on one set of dedicated ‘voice compute nodes’ (VCN) and all services such as call-routing, portal, API etc. sit on more generic ‘compute nodes’ (CN). We have VCNs in London and Slough presently, and CNs in both zones plus Manchester. VCNs are relatively lightweight with 16 Xeon cores and 32GB of RAM each, although each many times the size of the voice nodes they replace. The CNs are a bit beefier with 24-32 Xeon cores and 132-367GB of RAM each. All benefit from entirely SSD storage and 40Gb+ of network connectivity directly into both the sites’ ultra-low-latency core switching.
Anycast is a big change here too. We do not just anycast SIP, which we will make available in a few weeks time – intentionally a few weeks after the rest of the new stack. We have anycasted pretty much every component of our internal architecture. This is another Simwood first we believe and discussed in some detail in the Kamailio World 2017 video below. This gives huge benefits in terms of performance, availability and redundancy. The portal, API, and certain other services powering our now largely software-defined new network, have all been running on this platform and anycasted for some time with significant benefits.
The main benefit is performance, locality and availability; but there is a lot more than that. In the old days (still the future for some we won’t mention!), our developers would write code but needed someone to create a VM, someone else to configure the network, they’d deploy it and then between us we’d aspire to keep every element updated and consistent without breaking a live environment. With all of the above, an individual container can be taken down and rolled forwards or backwards, without affecting service. More importantly, our growing DevOps team now control service from writing code, through to the underlying network and security and of course operation. Their workflow involves more but is massively more consistent with lots of automation. This is a huge step forward for us and makes the dream of CICD that little bit closer. Previously you’d have noticed a portal upgrade, now the portal and API already change several times a day and new services do not require anybody involved except the developers creating them. Of course, at every stage we’re automatically including the latest security patches and versions. With this gone are the days of those big critical boxes that people have been too scared to reboot in 10 years; you know, the ones in other peoples networks!
So that’s what we’ve been up to. It is a huge piece of work for our team and I’m really proud of them. Do please give it all a whirl and let us know what you think!
‘Me too’ (we know you read very closely), you’ll want to hold down Control and press P for your RFP, and we’ll await your innovation press release or award in 2-3 years time!!!
Looking forwards, our deployment phases are as follows:
- Release beta stack – today
- Release anycast SIP proxy
- Migrate registration proxy (which remains in beta anyway) to new stack
- Migrate main proxy to new stack
- Migrate inbound calling to new stack
We’ll be working through that list over the next month or so, the timescale largely dependent on your feedback. Please do not wait for service to go ‘live’ and do engage and test. It is vital you test your environment with the new stack ASAP to avoid you having unforeseen issues when it is put live.
Finally, below are our various community talks about some of the technologies we’ve deployed here. These are in chronological order.
***
Videos
Kamailio World 2016 – Network protection, touching on Merchant Silicon & SDN
ClueCon 2016 – Merchant Silicon & SDN
ClueCon Weekly 2017 – Routing on the Host and Anycast
Kamailio World 2017 – Anycast in SIP Architectures
