By Simon Woodhead
In recent blog posts we’ve talked a lot about the Simwood Potato. I wanted to pull some of those threads together in one place.
Firstly, the ‘potato’ was never intended to be a product name. It was a metaphor I used writing a blog post while hungry. Colleagues have suggested alternatives such as ‘sarcophagus’ in the context of the structure used to contain the radiation from Chernobyl – ‘Purple Sarcophagus’ has a ring to it – and references from Hitchhiker’s Guide to the Galaxy such as ‘Magrathea itself disappeared’. While both convey the power of the potato, neither help people get what it is. Annoyingly, ‘potato’ works and risks sticking unless you guys can suggest something better!
So what the heck is it and why do we keep banging on about it?
As you know we own our network and we own our software stack. Our stack is integrated and active globally. Customers don’t get paired with a single SBC in one physical location, then need an incident team to migrate trunks to use a feature, or a load of paperwork to add another site. Rather, a customer can hit the entire stack simultaneously wherever the network extends and suits them. Take on a customer in California – direct traffic to our PoP there, it’ll work on your UK account seamlessly. We open a new PoP in Sao Paulo – direct your South American traffic there, it’ll just work. Add a new data-centre of your own – one API call to enable it. This cuts both ways though as any feature on the network is available across the entire network – so when we add a feature, it isn’t off the edge of a specific magic box that needs a migration to use but configurable with an API call on every single number on the network, including the millions we host for other operators. This core network might get bigger as we expand but it remains one deeply integrated mass that is different to any other carrier network out there. This is the potato.
Now, any good potato is wrapped in several layers of tin foil. These layers are services available, not only globally, but also simultaneously. They can be configured individually and in combinations on any number on the network for inbound calls, or any outbound call. Yep, you got it: they’re just features added to a trunk. So far the only service layer we’ve released in beta is call-recordings where we’ll push recording directly to you or your customer. It doesn’t sound much (to me at least), but remind yourself this is across the whole network, potentially on any call. That is where the potato differs from competitor architectures which would require a nominated number to be configured with a series of call trombones and points of failure. That’s just for call-recording! Remember, this feature is just a tick box (or boolean if you prefer the API) on a trunk and one of many which can be layered – just like tin-foil. Try doing that with a traditional back-to-back SBC architecture, let alone SQL Server 2000 and some old Ciscos!
We’re not stopping with call-recording. We’ve been exploring the art of the possible with AI with a major constraint: we’re not sending our customer data off to a cloud operator but need to keep it 100% on-net for security, privacy, and all those important things. We’ve had absolutely stunning results around translation, transcription, summarisation, sentiment analysis as well as modern solutions to old problems. The Simwood Potato means as we bring some of these into production, they are just more layers of foil around the core, available on every number on the network. We’ve got some big hardware on order but you’ll see the first AI services this year and they’ll be transformational for enterprise, call-centres and emergency services from what we’ve proved in the lab so far.
So we have this potato (global core), wrapped in multiple layers of foil (services/features). Now imagine skewers going into it. These represent the transports. So one skewer is PSTN – numbers hosted on the Simwood network, and calls out to other networks. Another is SIP – the primary interconnect we have with our customers. So first think of calls coming in and going out on each of those skewers – SIP-to-PSTN and PSTN-to-SIP. Each goes through every layer of tin-foil so can have any services enabled on it. Each goes into the core so can be geographically distanced too. There’re many skewers, to represent our geographic redundancy and the fact customers can use any of them for a given transport, but also for additional transports. So Teams has eight skewers, one for each of Microsoft’s Availability Zones. Zoom has skewers. There’re skewers for WebRTC, used by the Simwood Apps directly but available for others. And many more…
Now just as every call goes through every layer of foil and into the core, calls can be routed essentially any-to-any on the skewers. So you want call recording on that call which comes in over the PSTN and goes out to Teams or Zoom or WebRTC – done. You want AI summarisation, real-time intercept, and AI sentiment analysis on that call going into your call-centre – coming. You want a Reading PSTN number delivering calls to a Teams instance hanging off one of Microsoft’s Asian PoP – done. It is also any-to-any so that number might be configured to deliver calls to Teams, failing-over to Zoom if unavailable, or UCaaS regardless if it is 3pm on a Sunday.
As someone much younger said to me recently, and I’m tempted to adopt if only to annoy my daughters: “Are you feeling me bruv?”. This is immensely powerful and is going to enable our customers to address a multitude of needs more cost effectively, efficiently, and just plain better than the tangled mess of mediocrity available elsewhere. But there’s one more thing!
While the potato affects every single call on the Simwood Network, it is about to get a massive shot in the arm that has ramifications far outside the UK and the US. Whilst the platform supports SIP today, it is more SIP-to-PSTN or PSTN-to-SIP, or indeed SIP to any of the other supported “skewers” such as Teams. What is coming in Q2 is SIP-to-SIP, or put another way: BYOC. This enables us to extend the feature stack into other carrier networks, or customers of other carriers to benefit from Simwood features whether or not the other carrier plays ball.
So you’re a regional incumbent or mobile operator who wants to give call recording to all your users without massive architectural change – easy. Have numbering estate with Simwood competitors who want to charge you for encryption or don’t support modern codecs – no problem, have them deliver traffic to us and we’ll backhaul it to you on the existing secure integration. You use Simwood but want service overseas where we don’t have coverage? Rather than risking your fortune to someone claiming coverage in 170 countries, and losing it when regulators remind them they don’t, you can forge deep local relationships with proper local operators and use Simwood to backhaul the traffic with a single pane of glass and integration. Or maybe you have an international bank who need real-time translation and recording on all trading calls through the legacy PBX which trunks into you – sorted.
As you can hopefully see, the power of this is immense and we’re really excited!
