2-way SMS: Multiple operators with the same shortcode

Topic Keywords: 2-way SMS, PHP, routing, URL Parameters

This configuration issue comes up quite a bit.

Let’s say that you are connecting directly to multiple mobile operators, and your service is using the same short code on each operator. When customers send a message in to your short code, you want to make sure that the reply is sent back via the same mobile operator as which the message was received.

Additionally, if that message from the customer is a trigger to begin receiving updates from your service, you want to ensure that any additional messages that you send to the customer get routed back through the same mobile operator SMSC connection.

I’m going to address the simple 2-way SMS reply first.

If you are using the same short code on both SMSC connections, then replies will not automatically be directed out via the same SMSC connection from which the original message was received. (If you are using different short codes, then make sure that the appropriate short code is configured as the “Default Sender Address” for the SMSC connection, and this situation will fix itself.)

How to resolve this situation when using the same short code on multiple SMSC connections?

There’s a short easy answer, and a long more difficult answer.

Short (Easy) Answer:

If you’re running NowSMS v2008.03.22 or later, edit SMSGW.INI, and under the [SMSGW] header, add 2WayReplySameServer=Yes.

(Note: At the time this article was written, v2008.02.22 is the official download version. An updated release that includes this functionality, can be downloaded at https://nowsms.com/download/nowsmsupdate.zip.)

Restart the NowSMS server.

We could not make this setting a default, because there are actually quite a few NowSMS installations where for various operational reasons, 2-way SMS replies need to be sent out via a different connection from which they were received.

Note that this setting only applies to simple 2-way commands, where the command script returns a text response back directly. This setting does not apply when the “redirect technique” is used. That configuration is described in more detail in the Long More Difficult Answer.

Long (More Difficult) Answer:

For more advanced logic in 2-way command scripts, it is sometimes necessary to use the “redirect technique” that is described in the following document: https://nowsms.com/support/bulletins/tb-nowsms-003.htm

Alternatively, instead of using the “redirect technique”, your 2-way command script might initiate a new HTTP request to the NowSMS server to tell NowSMS to send one or more messages. For simple examples of this, see https://nowsms.com/discus/messages/1/3991.html, https://nowsms.com/discus/messages/1/867.html or https://nowsms.com/support/bulletins/tb-nowsms-008.htm.

With these types of 2-way command scripts, NowSMS passes the received message to the command script. But then the command script generates a new URL request back to NowSMS to send a message. In this context, NowSMS does not see the new URL request as a reply, so it cannot apply the desired routing logic.

This section describes how to achieve the desired routing logic when you are generating your own URL request for NowSMS.

The “Command to Execute” defined for your 2-way command script must include an @@SMSCROUTE@@ variable. When NowSMS passes the received message to your 2-way command script, NowSMS will replace @@SMSCROUTE@@ with the SMSC name (or assigned route name).

When your 2-way command script receives the message, it must parse the @@SMSCROUTE@@ value. This is how your 2-way command script knows the mobile operator SMSC connection from which this message was received.

If your 2-way command wants to reply back to the message, it needs to build a URL request for NowSMS. This URL request must include an “&SMSCRoute=xxxx” parameter which contains the original @@SMSCROUTE@@ parameter that was passed to the 2-way command. This tells NowSMS that the resulting message should only be sent out via that specified route.

By default, the @@SMSCROUTE@@ value is going to be the host name as defined in the NowSMS “SMSC” list (e.g., “SMPP – 10.1.1.1:9000” or “Modem – Bluetooth Modem”). It is possible to manually edit the NowSMS SMSGW.INI file to assign a more meaningful route name. Under the appropriate section header for each SMSC connection (e.g.,”SMPP – 10.1.1.1:9000″ or “Modem – Bluetooth Modem), it is possible to include a RouteName=xxxxxxxx parameter, where xxxxxxxx will instead be used as the @@SMSCROUTE@@ value.

I know what you’re saying … that seems complicated. It’s really not all that complicated … it just seems so because so far I’ve been too lazy to provide you with an example. I don’t know about you, but I usually do better with examples myself.

Let’s say you’ve got 2 SMPP connections to different mobile operators.

You’ve manually edited SMSGW.INI, and under one of the [SMPP – server:port] sections, you’ve added RouteName=Operator1, and under the other [SMPP – server:port] section, you’ve added RouteName=Operator2.

Let’s say that you’re using PHP for your scripting language, and you’ve created a PHP script named 2way.php which is installed on one of your web servers.

Configure the following 2-way command:

SMS Command Prefix = * (applies to all received messages, unless a better match exists)

Receive Phone Number(s) = (leave blank or put in your short code here to apply this script to messages only received by that short code)

Command to Execute = http://server/2way.php?sender=@@SENDER@@&text=@@FULLSMS@@&shortcode=@@RECIP@@&SMSCRoute=@@SMSROUTE@@

“Command Returns Response Text” should NOT be checked for this type of command script.

If the phone number 14435551212 sends a text message “TEST” to your short code 11111, and it is received via the SMSC connection defined with RouteName=Operator1, then the following URL would be triggered by NowSMS when the message is received:

http://server/2way.php?sender=14435551212&text=TEST&shortcode=11111&SMSCRoute=Operator1

Because of the indenting here, the script is a little difficult to follow. But basically, this script is just parsing the “sender” (@@SENDER@@ value), “text” (@@FULLSMS@@ value) and “smscroute” (@@SMSROUTE@@ value) parameters that were passed to the script.

The script then builds a new URL that it passes back to NowSMS to tell NowSMS to send a new message back to the sender via the same route as from which the message was received.

In this example, the script would return the following URL in a redirect response:

http://127.0.0.1:8800/?phonenumber=14435551212&text=I+received+your+message%3A+TEST&smscroute=Operator1

This URL redirect tells NowSMS to send a message back to the originator via the same operator SMSC as the originating message.

A few additional notes on this example….

This example assumes that the web interface for NowSMS is listening on its default port of 8800. If it is using a different port, the port number needs to be changed in the script.

127.0.0.1 assumes that this script will only be used if triggered by a NowSMS 2-way command. If you want to test the script by connecting to it from a web browser, change 127.0.0.1 to the IP address of the NowSMS server.

This example also assumes that “Require Authentication for web interface” is not enabled on the “Web” page of the NowSMS configuration. If this setting is enabled, then modify the “header” command in the script, so that after $_REQUEST[‘smscroute’] and before ); the following is added: . “&user=username&password=password”

The username and password values should match an account defined on the “SMS Users” page of the NowSMS configuration.

If you will be sending SMS messages to the subscriber outside of the context of a 2-way command, then you need to save the @@SMSCROUTE@@ value that you obtained when the subscriber originally sent into your system. You would save this value in your own database, maintained by your own applications, it is not saved by NowSMS. When sending any messages to that subscriber, generate a URL request for NowSMS that includes this route information in the “&SMSCRoute=” parameter.