As you all know, BYOC Inbound enables you to take an endpoint on the Simwood network to which you can route numbers from other networks. That endpoint can be associated with a Simwood trunk given a list of authorised IP prefixes to accept traffic from, and will diligently accept your calls to your third-party numbers onto the Simwood network and deliver them to you over that trunk exactly as if they were Simwood-native. This includes all features enabled on the trunk, such as call recording, transcoding, encryption, redundancy, etc.
That in itself is really powerful and has already enabled a number of early adopters to solve problems – like how to migrate an entire estate from a Simwood competitor overnight or how to deliver numbers onto your platform with feature parity.
For example, you now don’t need to pay your legacy carrier to buy an encryption licence for their magic box, something frankly they should have done as part of the “service” they charge you for. You can instead point their numbers directly at the Simwood BYOC endpoint and we’ll encrypt them before delivery on to you. This is already making a difference and demonstrating the value of Simwood BYoC in the real world.
However, what some of you have made us aware of is that a number of other operators cannot handle multiple different endpoints for a numbering estate and instead need a single SIP URI for a given account. This means a single BYOC endpoint has to carry the entire numbering estate which is fine from a volume point of view – you can point as many numbers at us as you like and don’t need to configure anything per number – but does create some limitations.
For example, where a customer is trying to migrate from a legacy platform to Simwood or wants some numbers mapping directly to customer endpoints, some other numbers to their platform and other numbers still somewhere else, this becomes tricky because it requires multiple trunks on the Simwood side.
Therefore today we’re adding Advanced routing to BYOC. With this, when you create a BYOC endpoint you also have the option to specify routing rules or matching number patterns. These can be as granular or general as you like and they enable specific sections of the numbering estate to be effectively peeled off and remapped to an alternative Simwood trunk.
This means that you can configure literally a single endpoint for millions of numbers on another network and let Simwood do the heavy lifting and add the value to them. It is rather like you’ve already deployed highly-available SBC’s globally (configured and managed uniformly), fully-loaded them with licenses (including for features which don’t exist on them), directly interconnected with anyone who is anyone, and could dump an entire numbering estate on it in a few clicks. Pretty cool I think and we’re only just scratching the surface of what this can do for you.
This feature will shortly be available in the portal and the API for those who are enrolled in our Carrier Services Beta Program and we really look forward to your feedback!
If you’d like insight into more of what is cooking right now, you might like our Q4 roadmap podcast (a.k.a SimCron3), or for a super high-level overview of why we’re doing all this, my talk at CCUK boils it down to 10 minutes. We also have numerous whitepapers!
