27 Feb Multitenant SMS Termination with Restcomm? “Easy Peasy”

SMS Routing and Termination is a big deal in the SMS ecosystem. Margins are high, looks easy, everyone wants to do it so do you. After all, it’s all about routing, having the connections, knowing the channel and having content providers lined-up, right?

Then you start from theory to practice. You’ll start with getting an SMSC, “ups”… not compliant with my ESME’s interface. Next, you’ll get an SMS Gateway, which leads to more $$. When you finally start integrating with the multiple service providers you want to work with, you’ll realize, “Damn”… you need an SS7 expert. Where can you find one these days? By now, six months have passed and you finally have your solution running. With all the money you’ve spent, margins are no longer as appealing as they were at the start (and you still didn’t have to scale up).

Once again, Restcomm comes to the rescue. Restcomm’s integrated multi-tenant SMSC capability allows you to interconnect through SMPP with as many CSPs as necessary. Furthermore, Restcomm is cloud-based. Not only will you be able to move more quickly to market but you won’t have to worry about scaling.

In this tutorial, I’ll show you the simplest way to achieve all of this.

1. Splitting Things

In order to make this work, I decided to split the system into two main components: Restcomm – to handle the multitenant SMPP links and Termination Logic. Termination Logic defines how and to whom you can terminate a certain short-message, while also maintaining a blunt and straightforward list of all the info associated with each provider, in this case, just Restcomm credentials per account are maintained).

2. Aggregating the Carriers

To interconnect to each carrier you are working with to terminate your short-messages, you’ll need to create a separate Restcomm Account or Sub-Account for each. I like to keep things clean so I’m creating a Sub-Account for each SMPP integration under my main Restcomm Account:

I can request Restcomm to make a different SMPP interconnection for each sub-account. In Restcomm, this is called “Bring Your Own Carrier.” You can learn how to do this here.

Once the interconnections are set, you are ready for the next step: building up your termination logic. Before we move onto that step, be sure to have the Restcomm Account details for each Sub-Account created (i.e. the AccountSID and Token for each termination carrier).

You can find these by clicking on the Sub-Account name:

3. Building Up the Termination Logic

This step is quite subjective. The logic can be as complex as you need it to be. SMS Termination systems are typically considered live-termination rates per carrier as well as other factors like stability of the connection, reliability, SLA, etc.

For my example, I kept it simple: destination country, i.e. looking at the country code of the terminating leg number and associating a specific carrier with that. So if I’m terminating the short-message in Portugal, I will use Carrier 1.  If it’s the UK  I will use Carrier 2, and so on.

I’m not worried about the complexity (or lack thereof) of the application, but rather showing how simple it is to leave the heavy SMPP work with Restcomm.

For my logic I created the following two main docs:

• a JSON file that keeps the Restcomm Account details per carrier (carriers.json):

{
    "portugal": {
        "carrier": "<<carrier1_name>>",
        "acctsid": "restcomm_accountsid_for_carrier1",
        "accttoken": "restcomm_token_for_carrier1"
    },
    
    "uk": { 
        "carrier": "carrier2_name", 
        "acctsid": "restcomm_accountsid_for_carrier2", 
        "accttoken": "restcomm_token_for_carrier2" 
    },
    
    "germany": { 
        "carrier": "carrier3_name", 
        "acctsid": "restcomm_accountsid_for_carrier3", 
        "accttoken": "restcomm_token_for_carrier3" 
    }
}

• a Node.JS script that creates the logic described previously, fetches the Carrier information from the JSON file and uses the Restcomm SMS API with the specific Carrier Account details I want to use (sendsms.js):

if (sms_to.match(/^44/) && obj.hasOwnProperty('uk')) { // for UK

    var rc_carrier = obj.uk.carrier
    var rc_accountSid = obj.uk.acctsid;
    var rc_accountToken = obj.uk.accttoken;

    auth = 1;
}

var rc_path = rc_restCommBase + '/'
    + rc_accountBase + '/'
    + rc_accountSid + '/'
    + rc_application;


var options = {
    url: 'https://' + rc_server + '/' + rc_path,
    auth: {
        username: rc_accountSid,
        password: rc_accountToken
    },
    form: {
        To: sms_to,
        From: sms_from,    // I want the origin to be a string
        Body: sms_body
    }
};

request.post(options, function (err, resp, body) {
    if (err) {
        return console.log(err);
    }
    console.log("[%s] DEBUG - Message Sent - Report Received:", timestamp);
    console.log(body);
});

Don’t bother taking notes. the code is quite simple and you can find it, make comments or propose changes directly in my Github account: https://github.com/fleitao/multitenant-sms-routing

In the end, you will be able to expose the following API to a content provider or ESME without exposing the termination logic that you are working with:

https://<<your_api_url>>/sendsms/send?from=123456789&to=9876543210&body=message

To recap, when executing that API the Termination Logic will: (1) check the prefix, (2) select the carrier, and finally (3) use the Restcomm SMS API to deliver the message through the carrier SMPP link.

No SS7 or SMPP knowledge needed!

Again, this is cloud so there is no scaling hassle. You can bring as many carriers as you need and termination coverage is ensured by the carriers you’re working with. Ultimately, you can even re-use the same logic in multiple regions you are working (pretty handy for travel agencies or airlines).

In a nutshell, it’s one application to rule them all

Didn’t work for you? Do you have any questions, comments or suggestions?

Feel free to shoot me an email and I’m happy to follow-up: filipe.leitao@telestax.com