We have for some time enabled you to create username/password combos for your end-users and pass outbound calls to us using them instead of the more usual IP address authentication. That is great as it not only gives you fine-grained fraud controls for individual end-users but we also pass you the trunk IDs back in reports, including fraud alerts and our real-time CDRs. This has always been outbound only though and operated from defined IP addresses, meaning you couldn’t practically use it for nomadic end-users and required them to register directly to your own equipment.
Effective in the latest update of the API we’re making trunks a whole lot more advanced which means for a large number of use cases you now do not need your own equipment at all! This is a no-cost* beta at this stage and we’re really interested to see how you get on with it.
Specifically:
- Outbound users can now be nomadic and therefore operate from any IP address.
- Users can REGISTER to dedicated proxies here and numbering (Simwood or even third party) can deliver calls there. There is no defined limit on the number of devices which can register to a trunk; they’ll all ring at the same time in the event of an incoming call.
- Trunks can now be configured as inbound, outbound or two way and, as before, enabled/disabled through the API.
- Caller-ID can be hardcoded for a trunk or, optionally, flagged to allow user equipment to specify it.
Functionality is live in the API now and this has been designed to work in a distributed fashion. You could have registrations to the same trunk on Simwood proxies in multiple sites and incoming calls will be routed appropriately.
This is not intended to be a PBX replacement and for applications requiring PBX functionality one will still be required. However, we see a lot of customers using PBXs simply to offer service to SoHo users where they need basic inbound and outbound calling on one or two devices and don’t need IVR or multi-party conferencing. This takes care of them.
Further, operating a PBX brings with it overhead and risk. This solution takes much of that away and, whilst you remain responsible for traffic sent on your account, the proxy employs all the learning from recent Simwood research into VoIP fraud. For example, it only operates over TCP and TLS, not UDP, uses SRTP by default, and has advanced filtering which makes it invisible to many types of attacker. It is also completely RAM based and very fast, so the days of your users not being able to register because someone is scanning your equipment could be behind you.
Looking forward, we see a time when our customers do not need to operate equipment at all for commodity applications. Instead, you’ll operate application servers which orchestrate your service through our API. If there’s a use case that would make that a reality for you today, do please let us know!
We really look forward to your feedback.
* There is no charge for trunks presently but to give customers testing the beta confidence that it will be economically viable going forwards, our plan presently is to charge trunks at £1/month each. This may be reduced, potentially to zero, where a trunk actively uses our numbering and termination.
