You can now configure numbers to route to multiple destinations, of multiple types, simultaneously as well as configure time of day routing, all at network level via our straightforward API.
Our API has always made it simple for customers to manage their numbers, supporting call forwarding to multiple destinations – PSTN or SIP as well as advanced anti-fraud and revenue protection measures like setting a max cost per minute on a leg, ideal for those offering their own number translation services built atop our platform.
End users typically demand more flexibility – the ability to set calls to route to different destinations based on the time of day, or ring multiple destinations simultaneously or in sequence (hunt groups) and this has necessitated use of an IP PBX or Softswitch (such as Asterisk, FreePBX, FreeSWITCH, 3CX etc)
The main advantage to these platforms is they offer you more control – but they also have the potential to introduce a single point of failure, and all RTP traffic flows in and out of your network for each leg of the call, increasing your bandwidth bills. Using Asterisk (or similar) simply to offer number translation with time-dependant routing (or a basic SIP registration service) is much like using a sledgehammer to crack a nut.
Introducing Advanced Inbound Routing
We’ve listened to customers who increasingly want to move as much as possible off-net, taking advantage of our dedicated network and infrastructure and resilient design and redesigned our call routing API to offer far more flexibility than before including;
- Easy Configuration of Per-Number Options
- Sequential and Simultaneous Routing
- Time (and Day) Dependant Routing
- Improved Fail-Over
The redesign is far more modular and allows us to easily add additional features to the number routing API going forward, following the same basic JSON-based framework.
We’ve also made the interaction with the API far more consistent. You can GET the configuration of a number, edit the JSON structure in place, and then PUT the replacement without the need to parse it into multiple delimited strings as before.
This is available in the Simwood API from Today but should be considered public beta. As always we welcome any feedback you have and encourage you to give us this by raising a ticket in the Support Centre.
For those of you who have integrated our existing routing into your applications – don’t worry – we’re not removing it, however it wont offer the flexibility of the new approach.
The latest API documentation can always be found here
Example
The config in a simple structured JSON format containing blocks that define how the number is routed. For example, to an inbound number to your customer’s PBX between 9am and 5pm, but forward to a mobile outside of these hours the configuration would look something like this;
{
"rules": {
"officehours": [
{
"dow": [1,2,3,4,5],
"time": [900,1700]
}
]
},
"routing": {
"officehours": [
[
{
"type": "sip",
"endpoint": "%e164@pbx.mycompany.com"
}
]
],
"default": [
[
{
"type": "pstn",
"number": "447700900123"
}
]
]
}
}
This is only the beginning, the new structured number configuration opens up many more possibilities that will be introduced in the coming months.
