Adding SMS to Voice

After months of continuous development, we are finally proud to release SMS-enabled version of SAARA system. It is built on our new SAARA engine, which in turn is based on field-proven Arrow/Longbow system.

The basic principle of the system is that we integrate SMS functions into existing system design, by making SMS services as one of the services our customers can offer. When previously everything was Voice telecom centered, now we have added more generalized approach, by making Voice services as one of the possible services, and adding SMS on equal terms. Of course, Voice is still dominant, as that is where we came from. But everything Voice related, is now being applied to the SMS as well. That includes a routing engine, real time authorization and accounting, as well as interface features.

Here are some more details:

1. Services

SMS services are supported in multiple ways:

1. MT messages sent either from Clients SMPP connector (binding to SAARA), RESTful API, or web interface
2. SMS enabled DID numbers. They can either receive MO messages via SMPP bindings, or see them on web interface. RESTful API support coming soon
3. Various monthly recurring fees based on DID number charges.
4. DID numbers can either be regular or toll-free, thus supporting per-message billing plans or flat rate plans. 

Here is how it looks in network context:

{$image2}

2. Carriers

Carrier now is a universal entity, and can have both Voice and SMS services. The Carriers can provide SMS services, and we have added SMPP-related entries to their settings. Each carrier can have multiple SMPP accounts, i.e. bindings which can be used to route messages to. Same as in voice, a rate table can be assigned to the carrier, and that affects how messages sent through this carrier, affects billing. Carriers can be 2-way, i.e. they can both support MO and MT messages. Carriers can be added to the routing by means of routing group.

3. Routing

We are giving higher prominence to the Routing now, by moving it out of Products and making it a separate top level entry. The reasons behind that is that routing functions have became more extensive, and secondly require separate access rights: i.e. persons responsible for routing are usually not the ones who set Products and Rates. Therefore Products and Rates and now separate. SMS routing is implemented similarly as Voice, with the exception that LCR is not ready yet. However, that is coming soon, together with some even more advanced routing modes.

4. Clients

Clients now has new tabs where you can manage their SMPP bindings, SMS-DID numbers, or RESTful API access credentials. Their invoices now include SMS related charges as well.

5. Architecture  

New blocks in the system are:

1. SMPP client/server - manages SMPP protocol, client bindings, server binding, message sending and receiving, delivery reports.
2. Authentication/Accounting module - new and rebuilt. Manages real time authentication and accounting. 
3. Routing engine - generates routing tables.
4. Cache - used to store routing tables for faster access. Also stores delivery reports and parts of multi-part messages.

The system, as with all SAARA products is scalable horizontally and vertically, i.e. components can be separated and installed on separate hardware units both for performance improvements and for redundancy.

Here is how it looks in general:

{$image1}

If you are interested to be a beta tester, please let us know here.