The NowSMS Tech Support Files

NowSMS PHP Example: Send MMS Message

2008-11-13T10:00:00.001Z

Continuing our series of PHP examples, today we'll revisit sendmms.php, which we originally published on our discussion board 5 years ago at http://www.nowsms.com/discus/messages/1/1113.html.

The sendmms.php script is considerably more complex than the sendsms.php script. The reason for this increased complexity is because an MMS message is more complex than an SMS message.

However, I have to admit that our 5 year old example can be a little difficult to follow. Over the years, I've answered quite a few questions about the script, as the way that you specify the files to include in the MMS message is a little confusing.

So in this posting, we'll update sendmms.php, and make it a little easier to follow.

The updated sendmms.php can be downloaded at http://www.nowsms.com/download/sendmms-php.txt.

The first part of sendmms.php consists of PHP functions that you will call in your PHP script ... namely MmsInit, MmsAddField, MmsAddFile and MmsSend. Include these functions in your script without editing them.

After these functions are defined, sendmms.php contains a simple example showing how to use these functions to send an MMS message through a NowSMS server.

1.) First, you need to initialise the parameters to point to your NowSMS server:

/* Set parameters for connecting to the NowSMS server */
$nowsmsHostName = "127.0.0.1"; /* IP Address or host name of NowSMS Server */
$nowsmsHostPort = "8800"; /* NowSMS Port number for the web interface */
$nowsmsUsername = "test"; /* "SMS Users" account name */
$nowsmsPassword = "test"; /* "SMS Users" account password */

2.) Second, you need to call MmsInit to initialise the MMS message structure.

$mmsMessage = MmsInit();

3.) Third, you need to add the necessary MMS header fields and attributes desired for your MMS message, calling the MmsAddField fuction.

$mmsMessage = MmsAddField ($mmsMessage, "PhoneNumber", "+447777777777");
$mmsMessage = MmsAddField ($mmsMessage, "MMSFrom", "sender@domain.com");
$mmsMessage = MmsAddField ($mmsMessage, "MMSSubject", "Subject of Message");

The "PhoneNumber" field specifies the recipient(s) for the MMS message. This can be a comma delimited list of phone numbers, or it can be the name of a NowSMS distribution list.

The "MMSFrom" field specfies the sender of the MMS message. Normally, this would be a phone number, short code or e-mail address. (And your MMS service provider may either require a specific value here, or they may overwrite the value you supply with the address associated with your service.)

The "MMSSubject" field specifies the subject of the MMS message.

Those are the most common MMS header fields. Optionally, you might also want to include an "MMSText" field to specify some text to be included in the MMS message. Text can also be included in an MMS message as a text file reference.

4.) Fourth, you specify the files to include in the MMS message using the MmsAddFile function. These files might be images, video, text, or other file types supported by the receiving device.

$mmsMessage = MmsAddFile ($mmsMessage, "f:\\temp\\filename.gif", "image/gif");

An MMS message can contain one or more of these included files. If you do not include a SMIL file component, NowSMS will build one automatically, so for full control of the MMS message presentation, you will want to include your own SMIL file, where you reference your file components by their short filename (without the full path, e.g., filename.gif ... NOT f:\temp\filename.gif).

The files referenced in the PHP script must be local files, residing on the same server as the PHP script. Remember to escape backslashes in the path so as not to confuse the PHP interpreter(c:\temp\file becomes c:\\temp\\file).

The last parameter of MmsAddFile is the MIME content type, e.g., "image/gif", "image/jpeg", "image/png", "text/plain" or "application/smil" ... however, note that current versions of NowSMS ignore the MIME content type when messages are submitted via the interface used by this PHP script. Instead, NowSMS uses the file extension to determine the content type (e.g., ".gif", ".jpg", ".png", ".txt", ".smil").

5.) Fifth and finally, you call MmsSend to submit the MMS message.

MmsSend ($nowsmsHostName, $nowsmsHostPort, $nowsmsUsername, $nowsmsPassword, $mmsMessage);

Those are the basics.

For the curious, the MmsAddField function can be used to specify any NowSMS URL parameter that is valid for sending an MMS message.

For example ... here is an incomplete list of additional parameter fields that can be specfied using the MmsAddField function.

"MMSFile" - As I've noted above, this script attaches local files to the MMS message. However, what if you want to include files that reside on a separate web server instead? In that case, do not use the MmsAddFile function. Instead, use $mmsMessage = MmsAddField ($mmsMessage, "MMSFile", "http://www.nowsms.com/media/logo.png" ); and specify the file components as URL references via the "MMSFile" parameter field.

"MMSDeliveryReport" - "Delivery Report" specifies whether or not a delivery report is requested for the message. Set to "Yes" to request a delivery report. Note that any delivery report would be directed back to the phone number or e-mail address specified in the "MMSFrom" address.

"MMSReadReport" - "Read Report" specifies whether or not a read receipt is requested for the message. Note that the receiving client may choose not to send a read receipt. Any read receipt report would be directed back to the phone number or e-mail address specified in the "MMSFrom" address.

"MMSPriority" - "Priority" is a user defined priority to be associated with the message. Generally, any priority definition associated with the message is ignored by the underlying transport, but the receiving client may decide to display messages differently based upon this priority setting.

"MMSMessageClass" - "Message Class" is an attribute defined in the MMS specifications. "Personal" is the message type that is used for standard user-to-user communications. Other defined message classes that are supported by this parameter include: "Informational" and "Advertisement".

"MMSWAPPush" - Set to "Yes" to indicate that the message being sent should be sent as an "Multimedia WAP Push" message instead of as an MMS message.

It is also possible to specify forward locking and DRM constraints to be applied against the content of the MMS message. Forward locking and DRM constraints apply to non-text parts of the MMS message (i.e., in a forward locked message, text could still be forwarded, but images or video could not). Please note that not all devices support forward locking and DRM constraints, therefore use these parameter settings only after testing thoroughly with mobile phones used by your message recipients.

"MMSForwardLock" - Forward locking is the most basic level of DRM (Digital Rights Management). When "Forward Lock" is set to "Yes", this indicates that the receiving device should not allow any non-text objects in the message to be forwarded off of the device. The device may allow the user to extract pictures, videos or sounds from the message and save them on the phone. However, any such objects remain forward locked, such that they cannot be forwarded to another user or transferred to another device. (IMPORTANT NOTE: NOT ALL DEVICES SUPPORT FORWARD LOCK, WHEN NOT SUPPORTED THE CONTENT WILL APPEAR AS GARBAGE OR MAY BE REJECTED BY THE OPERATOR MMSC.)

"DRMRestrict" - Beyond forward locking, More advanced DRM (Digital Rights Management) restrictions can be applied to limit the number of times that the user can access an object, or start and end dates can be specified to limit how long the user can access an object.
These advanced DRM restrictions can be applied by setting "DRMRestrict" to "Yes". When this setting is enabled, forward lock is also implied, and the value of the "MMSForwardLock" setting is ignored. (IMPORTANT NOTE: NOT ALL DEVICES SUPPORT DRM RESTRICTIONS, WHEN NOT SUPPORTED THE CONTENT WILL APPEAR AS GARBAGE OR MAY BE REJECTED BY THE OPERATOR MMSC.)

"DRMRestrictTextXML" - "Yes" specifies that the rights object should be encoded in text XML format. "No" specfies that the rights object should be encoded in binary XML format. The default is "No".

When DRM Restrictions are specfied, it is generally necessary to specify one or more DRM Permissions and one or more DRM Constraints regarding the MMS message content.

DRM Permissions specify what types of access are allowed against the objects in a message that is protected with DRM.

For example, an audio or video object requires "Play" permission before the user can access it. An image requires "Display" permission before the user can access it, and it requires "Print" permission if the user is to be allowed to print the image to a printer , perhaps over Bluetooth. An application requires "Execute" permission before the user can make use of the application. In all cases, the forward locking is assumed, so that the user is not allowed to forward or transfer the object from the device.

If you are sending multiple types of objects in the MMS message, specify all permissions that are required for the different types of objects that are being sent.

"DRMPermissionPlay" - Set to "Yes" to enable DRM "Play" Permission.

"DRMPermissionDisplay" - Set to "Yes" to enable DRM "Display" Permission.

"DRMPermissionExecute" - Set to "Yes" to enable DRM "Execute" Permission.

"DRMPermissionPrint" - Set to "Yes" to enable DRM "Print" Permission.

DRM Constraints specify constraints with regard to how long a DRM protected object object should remain accessible to the user.

"DRMConstraintCount" - "# of Accesses (count)" specifies the the user can only access the DRM protected object this number of times before access is no longer allowed.

"DRMConstraintStart" - "Start Date (yyyy-mm-dd)" specifies that the user will not be allowed to access the DRM protected object until on or after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2008-12-24.)

"DRMConstraintEnd" - "End Date (yyyy-mm-dd)" specifies that the user will not be allowed to access the DRM protected object after the specified date. (Note that you must specify the date in yyyy-mm-dd format, e.g., 2008-02-24.)

"DRMConstraintInterval" - "# of Days (interval)" specifies that the user will be allowed to access the DRM protected object for this number of days after initial receipt of the object. The user can either enter a number of days here, or they can enter any valid value defined for the "" element in the OMA DRM Rights Expression Language specification. For example, P2Y10M15DT10H30M20S represents a duration of 2 years, 10 months, 15 days, 10 hours, 30 minutes and 20 seconds.

NowSMS Update Available for Test Release

2008-11-05T18:51:00.002Z

Over the past several months, we have been working on some optimisations and performance enhancements to the core SMS message routing logic of the NowSMS product.

These enhancements have been geared primarily toward supporting higher volume messaging environments with speed requirements of 400 messages per second and higher.

These core performance enhancements are also of interest to other high speed, but not-quite-as-high-speed environments for a variety of reasons.

1.) Requesting delivery receipts for all (or most) messages can put an increased strain on the system, with previous versions of NowSMS peaking at speeds of 150 to 200 messages per second when delivery receipts are requested, and sometimes with a queued backlog of receipt processing. Performance is easily doubled in this update, and the queue backlog has been eliminated.

2.) 2-way SMS command performance has been optimised, particularly for HTTP based commands, allowing an HTTP based command to easily keep up with burst rates of hundreds of messages per second. (For more preliminary information, see http://www.nowsms.com/discus/messages/1/24486.html.)

3.) CPU load with large numbers of outbound messaging routes. Historically, the more outbound routes defined to NowSMS, the higher the CPU load, especially if there is a large volume of queued messages waiting for a small number of routes. The routing logic has been dramatically improved to reduce CPU load.

4.) If you use HTTP-based accounting callbacks for billing or accounting, they may be significantly limiting your overall message throughput. The new release uses HTTP keep-alive sockets and optimised logic to improve throughput when accounting callbacks are enabled.

There are also a number of new features in this release. A list of features and enhancements from the readme file can be found at the end of this message. However, the primary focus of this NowSMS update is performance.

We've completed our internal testing of this update. However, because there were a large number of internal changes, optimisations and fixes, we are going to make this version available as a test release before general release.

We're quite confident that this release is actually more stable and robust than previous versions. We know the performance and CPU overhead is much improved. We know that overall disk I/O has been reduced. And we know several rather significant bugs that have been fixed in this release. But, the problem with bugs is they are very much configuration dependent, and with such a large number of configuration options, we may have missed something that affects articular configurations, so we want to get some more feedback.

For this reason, we're going to go ahead and make this update available in a testing release prior to a more general release.

This update can be downloaded at http://www.nowsms.com/download/nowsms200811.zip.

A full list of changes can be found in the readme file included with this release, or is also avaialble at the following link: http://www.nowsms.com/discus/messages/53/24488.html

We will be detailing some of the other enhancements in future postings here, but here is a brief overview of some of the more significant features:

1.) Enhanced SMS Message Routing Logic - Recipient address masks can now specify addresses to exclude from the selected route, in addition to the existing inclusive logic. Additionally, the SMPP service_type value can be used as a basis for SMS message routing. Some additional preliminary information can be found in the following message thread: http://www.nowsms.com/discus/messages/1/24460.html

2.) Dynamic SMS Message Routing Callbacks - This capability is long overdue! It has been availalble for MMS message routing for some time. Essentially, the existing HTTP accounting callbacks have been extended to allow the callbacks to dynamically specify which outbound route should be used for SMS message routing. Some additional preliminary information can be found in the following mesasge thread: http://www.nowsms.com/discus/messages/1/23919.html

3.) Explicit SMSC Routing available to SMPP Clients - Perhaps not as signicant as the other enhancements, but it is now possible to give SMPP clients connecting to NowSMS as their SMPP server more control over outbound SMSC routing if desired. Some additional preliminary information can be found in the following message thread: http://www.nowsms.com/discus/messages/1/24485.html

4.) Bug fix that could cause an SMPP client connection to "hang" - See http://www.nowsms.com/discus/messages/1/24483.html

5.) Throttling support for outbound MMS routing speed for external MM7, MM4 or EAIF connections.

6.) Enhanced support for the "mailto:" command as used in 2-way commands for routing received SMS messages to e-mail. Additional preliminary information can be found in the following message thread: http://www.nowsms.com/discus/messages/1/24428.html.

7.) More flexibility in controlling message retry behaviour in UCP/EMI and CIMD environments, as described in the following post: http://blog.nowsms.com/2008/10/sms-retry-error-handling-with-ucpemi.html

8.) Delivery receipts are now supported for UCP/EMI and CIMD environments, with NowSMS automatically translating message receipts for those environments into SMPP format to simplify processing.

9.) MMSC/MM4 Enhancements for improved real-world compatibility with more MMS interconnect services.

MMS Conversion to SMS With Web Link

2008-10-23T09:00:00.000Z

When using the NowSMS MMSC, one of the MMS routing options is to convert an MMS message to an SMS message with a web link.

This setting is most often used in operator MMSC configurations for one or more of the following configurations:

1.) Delivering an MMS message to a mobile phone that does not support MMS. (This is most frequently used in conjunction with auto-provisioning, where MMS compatible phones are automatically provisioned on the NowSMS MMSC. For more information on auto-provisioning, please see http://www.nowsms.com/support/bulletins/tb-nowsms-002.htm.)

2.) Delivering an MMS message to an international recipient for which there is no available MMS interconnection.

3.) It is also possible to configure a delay period where any pending MMS messages are converted to SMS messages with a web link if it is not retrieved within a configurable timeout.

This article will describe configuration settings relevant to one or more of these scenarios.

Sending MMS Message – Convert to SMS with Web Link

The "MMSC Routing" page of the NowSMS configuration defines all external routes for MMS message delivery.

The NowSMS MMSC will always perform direct MMS delivery as an MMSC for any subscribers that are registered with the MMSC. These subscribers could be manually or automatically provisioned, and they will be listed on the "MMSC Users" page of the NowSMS configuration.

Routing for MMS message recipients that are not subscribers of the MMSC is defined on the "MMSC Routing" page of the NowSMS configuration.

The routing type "Convert to SMS with Web Link" defines that any MMS messages sent via this route should be converted to an SMS message that includes a link to a web page where the recipient can go to retrieve the content of the MMS message.

For example, when sending an MMS message to a recipient that does not have an MMS compatible phone, or to an international recipient to which there is no available MMS interconnection, the recipient can instead receive an SMS message similar to the following:

Multimedia message from +4477777777. To view, go to http://mms.operator.com, and enter code number 1234.

The recipient can then navigate to the web link using a WAP browser on a mobile phone, or a web browser on a PC. They will be prompted for their phone number and the code number that was supplied in the SMS message. After entering that information, the message content will be displayed in the browser.

Frequently, this type of route is configured as a default route, which means that this route is used if a recipient was not in the "MMSC Users" list, and not covered by a recipient address mask in another "MMSC Routing" definition.

The following configuration settings are required for this type of routing:

"Local Server Port" specifies an available port number on the PC running NowSMS which will be used to accept connections from recipients who are attempting to connect in to retrieve MMS messages over the web interface. This port number must be different from other port numbers configured for use by NowSMS. This port must be unique, because the only functionality provided through this interface is MMS message retrieval over the web interface. Other NowSMS ports will likely have restricted access via a firewall, however this port needs to be open to the outside world to allow these types of messages to be retrieved.

"Local Server URL" specifies the externally accessible URL that recipients will access to connect to the "Local Server Port" on the MMSC. This setting will default to the "Local Host Name or IP Address" configured for the MMSC, and the "Local Server Port". However, if you are remapping the address and port via a firewall, you should specify the external host name (and port if required) in this field. Keep in mind that some users may be restricted from retrieving content from non-standard web server ports.

"SMS Message Text" is a template for the SMS text message that will be sent out to recipients. This text should consist only of characters that are part of the default GSM character set. And it should include the following replaceable text parameters:

@@PhoneNumber@@ will be replaced with the phone number of the message sender.
@@Server@@ will be replaced with the value configured for "Local Server URL".
@@Code@@ will be replaced with a code number that the recipient must enter in order to retrieve the MMS message content.

The default text for this message is:

"Multimedia message from @@PhoneNumber@@. To view, go to @@Server@@ and enter code number @@Code@@."

"Use MMS Sender as SMS Sender" - This option specifies that the SMS message that is sent out should use the sender address from the original MMS sender, if the original MMS sender was a phone number.

Web Link Template Files

HTML (XHTML Basic) and WML template files are used to construct the login page and message files generated by this facility.

These template files must be located in a subdirectory of NowSMS named "MMSSMS".

The templates for the login page are LOGIN.WML and LOGIN.HTM.

The templates for message file creation are MSGTEMPLATE.WML and MSGTEMPLATE.HTM.

These templates can also reference GIF or JPEG files that are located in the same "MMSSMS" directory. The default templates make use of two GIF files, CLOSE.GIF and OK.GIF.
NowSMS will automatically load either the WML or HTML (XHTML Basic) template, based upon the capabilities of the device.

Converting to SMS with Web Link After a Delay

It is also possible to configure the MMSC such that it if an MMS message is not retrieved from the MMSC within a configurable timeout period, the MMSC will then convert the message to SMS, sending a text SMS message to the recipient, with a URL like that can be used from either a phone or PC browser, to retrieve the content of the message.

To enable this SMS conversion, it is necessary to define an "MMSC Routing" of the type "Convert to SMS web Web Link", as described above.

Once that routing is defined, edit MMSC.INI, and add the following settings under the [MMSC] header:

UndeliverableRouteToSMS=VASPOutboundRouteName

Specifies the name of an MMSC Outbound Route that is defined in the "MMSC Routing" list, which must be of the type "Convert to SMS with Web Link". By default, if an MMS message has not been retrieved within 120 minutes, the message will be rerouted to be sent as an SMS with a web link for accessing the MMS content.

UndeliverableRouteToSMSTimeout=####

#### is a value in minutes that changes the time period after which the UnderliverableRouteToSMS setting is applied.

NowWAP, Radius Accounting and MSISDN headers

2008-10-21T09:00:00.002Z

NowWAP was recently updated over the summer months to address an issue on heavily loaded systems where Radius packets could be lost. NowWAP uses these Radius accounting packets in order to determine the identity (phone number or MSISDN) associated with the device that is making a request. NowWAP includes the phone number in an X-MSISDN header when forwarding the request to a downstream content server, which enables content server, such as an MMSC to identify the subscriber.

On extremely busy systems, NowWAP was not processing Radius requests quickly enough, which could cause some packets to be lost, resulting in rejected connections.

This problem was corrected in the 2008.06.03 release of NowWAP, which is currently available for download at http://www.nowwap.com/.

More information about how to configure NowWAP and the NowSMS MMSC to use a Radius accounting feed can be found at http://www.nowsms.com/support/bulletins/tb-nowsms-002.htm.

Additional information about configuring a Radius accounting feed in a fault tolerant and/or load balanced installation of multiple NowWAP servers can be found at http://blog.nowsms.com/2008/06/nowwap-in-fault-tolerant-or-redundant.html.

NowSMS PHP Example: Send SMS Text Message

2008-10-17T09:00:00.002Z

Over the coming weeks, I'm planning to collect various PHP, ASP and other script examples to provide some examples of how to interface with NowSMS from those environments.

The following links should provide all of the relevant postings, assuming that I follow-up with this task as planned.

PHP Examples -- http://blog.nowsms.com/search/label/PHP

ASP Examples -- http://blog.nowsms.com/search/label/ASP

Command Line Script Examples -- http://blog.nowsms.com/search/label/command%20line%20interface

We'll start with the simplest of examples, sending an SMS text message from a PHP script.
It was almost five years ago that we posted an example PHP script for this task on our discussion board at http://www.nowsms.com/discus/messages/1/867.html.

Below I've included basically the same five year old script, but I've added some minor comments for further clarification.

The SendSMS function is the important part of the example. This is the function that needs to be included in your PHP script. You call this function, specifying the host name or IP address and port number of the NowSMS server, along with a username and password for an "SMS Users" account on the NowSMS server, plus the recipient phone number and text of the SMS message.

The SendSMS function uses these parameters to build a URL for connecting to the NowSMS server. This function could be easily modified to support sending other types of messages by modifying the URL that the function creates. For additional information on NowSMS URL parameters, see http://www.nowsms.com/documentation/ProductDocumentation/sending_messages/url_parameters_for_sending_messages.htm.

Following the SendSMS function, we show two examples of how this function might be called from within a PHP script.

The first example shows hard coded parameters being passed to the SendSMS function.

The second example shows how a web form could post to the PHP script. The PHP script parses the variables received from the web form, and passes those variables to the SendSMS function to trigger NowSMS to send a message.

<?

function SendSMS ($host, $port, $username, $password, $phoneNoRecip, $msgText) { 

/* Parameters:
    $host - IP address or host name of the NowSMS server
    $port - "Port number for the web interface" of the NowSMS Server
    $username - "SMS Users" account on the NowSMS server
    $password - Password defined for the "SMS Users" account on the NowSMS Server
    $phoneNoRecip - One or more phone numbers (comma delimited) to receive the text message
    $msgText - Text of the message
*/
 
    $fp = fsockopen($host, $port, $errno, $errstr);
    if (!$fp) {
        echo "errno: $errno \n";
        echo "errstr: $errstr\n";
        return $result;
    }
    
    fwrite($fp, "GET /?Phone=" . rawurlencode($phoneNoRecip) . "&Text=" . rawurlencode($msgText) . " HTTP/1.0\n");
    if ($username != "") {
       $auth = $username . ":" . $password;
       $auth = base64_encode($auth);
       fwrite($fp, "Authorization: Basic " . $auth . "\n");
    }
    fwrite($fp, "\n");
  
    $res = "";
 
    while(!feof($fp)) {
        $res .= fread($fp,1);
    }
    fclose($fp);
    
 
    return $res;
}


/* This code provides an example of how you would call the SendSMS function from within
   a PHP script to send a message.  The response from the NowSMS server is echoed back from the script.
 
$x   = SendSMS("127.0.0.1", 8800, "username", "password", "+44999999999", "Test Message");
echo $x;

*/

/* This code provides an example of sending a message via NowSMS as the result of a web form posting.

   First, here's a very simple HTML web form that provides an example of what you need in your
   web form.

<HTML> 
<HEAD><TITLE>Send SMS</TITLE></HEAD> 
<BODY> 
<form method="post" action="sendsmsscript.php"> 
<table border="1"> 
<tr> 
<td>Mobile Number:</td> 
<td><input type="text" name="phone" size="40"></td> 
</tr> 
<tr> 
<td valign="top">Text Message:</td> 
<td><textarea name="text" cols="80" rows="10"></textarea> 
</tr> 
<tr> 
<td colspan="2" align="center"> 
<input type="submit" value="Send"> 
</td> 
</tr> 
</table> 
</form> 
</BODY> 
</HTML> 

   Second, here's the PHP script that would parse the parameters from the form posting, and then call
   the SendSMS function to submit the message.

if (isset($_REQUEST['phone'])) { 
   if (isset($_REQUEST['text'])) { 
      $x = SendSMS("127.0.0.1", 8800, "username", "password", $_REQUEST['phone'], $_REQUEST['text']); 
      echo $x; 
   } 
   else { 
      echo "ERROR : Message not sent -- Text parameter is missing!\r\n"; 
   } 
} 
else { 
   echo "ERROR : Message not sent -- Phone parameter is missing!\r\n"; 
} 

*/
 
?>

NowSMS and Multitech CDMA Modem

2008-10-15T09:00:00.000Z

NowSMS is primarily used for sending and receiving SMS and MMS messages in GSM environments.

In GSM environments, there have been long established standards for special "AT commands" used for sending and receiving SMS messages using a GSM modem interface.

We sometimes get questions about using NowSMS with operators that use CDMA technology. This question comes up most frequently in North America, where Verizon and Sprint are major mobile operators using CDMA technology, while AT&T and T-Mobile use GSM technology.

When we talk about GSM modems, we use the terminology GSM modem as a generic term to refer to any modem that supports one or more of the protocols in the GSM evolutionary family, including the 2.5G technologies GPRS and EDGE, as well as the 3G technologies WCDMA, UMTS, HSDPA and HSUPA.

The GSM modem standards were originally defined in ETSI GSM 07.05 and ETSI GSM 07.07. They have evolved and been further enhanced for 3G environments that are an evolution of GSM, and are published in 3GPP TS 23.005 and 3GPP TS 23.007.

Unfortunately, similar standards were never devoloped for CDMA environments, including CDMA2000 and EVDO which are the 3G evoluationary paths for CDMA.

However, there are some CDMA devices that provide some support for the AT commands defined for GSM modems. One such family of devices that we encounter somewhat frequently is the Multitech MultiModem CDMA (http://multitech.com/PRODUCTS/Families/MultiModemCDMA/).

NowSMS automatically detects that these modems can be used for sending and receiving text messages (they cannot be used for sending any binary SMS message types). However, a bug in recent firmware versions of these modems causes problems for NowSMS. The problem typically manifests itself with NowSMS reporting "ERROR - Error waiting for response from modem (1)". This problem is caused by a bug in the modem's implementation of one of the important AT commands for sending/receiving SMS.

Until this modem bug is fixed, we have added a configuration setting in NowSMS v2008.09.09 and later.

If you experience the error "Error waiting for response from modem (1)" with a Multitech CDMA modem, try editing SMSGW.INI, and under the [Modem - driver name] section header, add ModemSendWorkaround=Yes.

An update for NowSMS that includes this work-around can currently be downloaded at http://www.nowsms.com/download/nowsmsupdate.zip.

Note that NowSMS can only be used to send and receive text SMS messages with this CDMA modem. It might be possible to also send MMS messages ... if anyone with a Multiech Multimodem CDMA device is interested in exploring this, please visit us on the NowSMS Discussion Board at http://www.nowsms.com/messages.

OMA MMS Postcard conformance

2008-10-14T09:00:00.000Z

An odd question came in via e-mail, and I thought it was worth noting here...

Please confirm the below feature is supported in Latest version of
NowSMS:

MMS postcard services Under "OMA MMS specs 1.3" is supported in "Jun 2008 Now SMS version".

What is an MMS postcard?

MMS Postcard is a name for a collection of person-to-service/application services where multimedia content of an MM is printed and physically delivered to recipient via postal services.

Basically the idea behind MMS Postcard support is that you snap a picture with your camera phone and send it to your grandmother as a conventional postcard that she receives in the post.

Behind the scenes what happens is that the MMS message is actually sent to a phone number or short code. One or more images is included in the MMS message, along with one or more VCARD objects. The VCARD object contains a physical address to which the post card should be mailed.

From a NowSMS MMSC perspective, there is no requirement for any additional functionality to support OMA MMS Postcard conformance.

All of the conformance requirements defined in the relevant OMA MMS Conformance specification for postcards are client based, not server based.

From a server perspective, the server only needs to be able to support VCARD objects in the MMS message. NowSMS does support VCARD objects in an MMS message.

There is an optional client element, the X-MMS-GREETINGTEXT header, defined as optional for postcard conformance, which NowSMS does NOT support.

The primary reason that NowSMS does not support this is because this header is defined only for MM1 in the OMA specifications. It is not defined in the 3GPP specifications for MM4, MM7 or any other MMS interfaces. The typical usage case for an MMS postcard would be that the MMS client would attach the physical addresses to the MMS message as VCARD objects, and send the message over MMS to a short code. The short code would be routed to a postcard service via MM7. MM7 does not define any mapping for the X-MMS-GREETINGTEXT header, therefore it is not possible to deliver this header to a postcard service. This is why NowSMS cannot support this optional header.

I don't expect MMS postcards to be a major business, but if they are, I guess the NowSMS MMSC is ready for them.

mBlox and NowSMS

2008-10-08T09:00:00.002Z

Here at NowSMS, we make it a point not to endorse any particular SMS service provider. The fact of that matter is that bulk SMS services are a volatile business, and we like our customers to have flexibility to choose and change SMS service providers that best fit their needs.

That said, some SMS service providers have unique configuration attributes, and you need to apply special configuration parameters in NowSMS in order to take advantage of features and flexibility offered by the SMS service provider. This is especially the case with premium rate SMS services.

mBlox uses a number of special parameters, some of which are specific to their service only. So for customers who are looking to use NowSMS with mBlox, I want to highlight some of these settings and parameters.

This should not be construed as an endorsement of mBlox by NowSMS, or vice versa. This is just information that is provided to help simplify the process of integrating NowSMS with the mBlox service.

There are a series of special SMPP parameters that mBlox defines for their service. SMPP is flexible in that it allows service providers to define additional parameters in the optional TLV (tag, length, value) section of the SMPP message packet.

To enable the additional mBlox parameters in NowSMS, it is necessary to manually edit the SMSGW.INI file and and add the following section:

[SMPPOptions]
mblox_operator=1402,String,5
mblox_tariff=1403,String,5
mblox_sessionid=1404,String,45
user_message_reference=204,Integer,2

The above text should be added to the SMSGW.INI file "as is". "String" and "Integer" are not place holders for you to replace when adding this information to the SMSGW.INI file, so please avoid that common mistake.

These parameters are provider specific, and you are telling NowSMS that there are additional parameters supported by your provider, and these settings tell NowSMS the parameter type (e.g., "String"), length restrictions, and the SMPP parameter value.

When these settings are present, additional parameters are supported when submitting a message to NowSMS via an HTTP URL request.

"&SMPPOption_mblox_operator=" can specify a value for the destination operator.

"&SMPPOption_mblox_tariff=" can specify a value for the premium rate tariff associated with the message.

"&SMPPOption_mblox_sessionid=" may be required for some premium rate SMS operator implemtnations.

"&SMPPOption_user_message_reference=" is a generic option that allows you to set/retrieve the value of the SMPP "user_message_reference" variable. An mBlox FAQ suggests that it is possible to use this option to specify a billing reference.

For additional information on any of these parameters, please refer to the mBlox SMPP Gateway Manual.

Please note that mBlox support will often suggest that you use a value of "0" for the mblox_tariff initially. However, customers have reported to us that mBlox appears to require a 5 digit code for this field, and that "00000" should be used instead of "0".

When these SMSGW.INI file settings are present, NowSMS will also route these parameters to HTTP-based 2-way commands. If a message is received which contains values for either of these settings, NowSMS will automatically append "&SMPPOption_mblox_operator=value" and/or "&SMPPOption_mblox_tariff=" to the 2-way URL. It is not necessary to add any variables to the 2-way command template, as these values will be appended automatically if present in a received message.

In addition to supporting these options via HTTP URL request, it is possible to configure default settings for any of these options for each outbound SMPP connection.

In many cases, it may be desirable to define default values for these parameters, instead of having to specify them in each HTTP URL submission. To define default values for these parameters, manually edit the SMSGW.INI, and in the section header for an SMPP connection (e.g., [SMPP - ip.address:port]), add a "DefaultSMPPOptions=" setting, where the value of this setting can contain any of the "SMPPOptions" settings. For example, "DefaultSMPPOptions=mblox_tariff=00000". To include multiple options, separate the entries with a ";", for example, "DefaultSMPPOptions=mblox_tariff=00000;user_message_reference=1".

In addition to the above parameters, mBlox uses some additional parameters and terminology which differs slightly from NowSMS terminology.

The "originator" is the "Sender Address", or "short code" associated with your serivce. You will want to configure this value as the "Default Sender Address" for the mBlox SMPP SMSC connection that you define to NowSMS.

"ProfileID" equates to the "Serivce Type" parameter in SMPP. Do not confuse "Service Type" with "System Type". "System Type" is an SMPP parameter that is sent at initial login (bind). "Service Type" is a parameter that is set for each message that is sent. While "System Type" can be easily defined via the NowSMS user interface, in order to define a default "Serivce Type" value, it is necessary to edit the SMSGW.INI file, and under the [SMPP - server:port] header (server:port will be replaced with the address of your SMSC), specify: ServiceType=value (value is the value that you want to be specified as the service type). It is also possible to override the default Service type value when submitting a message to NowSMS via SMPP by including "&ServiceType=value" in the HTTP URL string.

When we work with customers who are interfacing NowSMS with mBlox, the issues that we typically see are this:

1. ) Make sure that you have the [SMPPOptions] section defined in SMSGW.INI exactly "as is" ... do not replace "String" with some other value.

2.) Define your short code as the "Sender Address" for the SMPP SMSC connection.

3.) Make sure that you have your DefaultSMPPOptions= settings under the [SMPP - server:port] section of SMSGW.INI for the SMSC connection that you have defined (e.g., under [SMPP - smpp.psms.us.mblox.com:3209]). mBlox documentation will tell you what settings you need to specify, but generally you will need to specify an mblox_tariff value (e.g., "DefaultSMPPOptions=mblox_tariff=00000").

4.) If you require a specific profile id, include ServiceType=value under the [SMPP - server:port] section of SMSGW.INI.

5.) If you need to use parameters other than the defaults for specific messages, then when you submit the message to NowSMS include URL parameters to override the defaults (e.g., "&SMPPOption_mblox_tariff=00000&ServiceType=123").

2-way SMS Command Speed and Performance (updated)

2008-10-07T09:00:00.004Z

Before I get to the speed/performance issue that I want to highlight, I'll review some of the basics of 2-way SMS in NowSMS and provide a few starter links for beginners who might have stumbled upon this post.

The 2-way SMS facility of NowSMS is designed to facilitate the processing of inbound, or mobile originated, SMS messages.

When NowSMS receives an SMS message, it will evaluate the content of the message, and can either execute a program, or connect to an HTTP URL (such as a PHP, Perl or ASP script), passing the content of the received message to program or script.

The basics of 2-way SMS are described in the NowSMS manual and at the following link:
http://www.nowsms.com/documentation/ProductDocumentation/2_way_sms_support.htm

A good basic troubleshooting guide for initially setting up 2-way SMS can be found at the following link: http://www.nowsms.com/discus/messages/1/4520.html

The above link also has some simple PHP and ASP examples for processing received SMS messages.

If you are processing more than 10 inbound SMS messages per second, it may be necessary to configure NowSMS to allocate more threads for the 2-way command processing, depending on the speed of your 2-way command script.

NowSMS will receive messages from the SMSC connection as quickly as it can, so that messages do not backup at the service provider.

After receiving the SMS messages from the service provider, NowSMS queues the received messages, and a separate thread within NowSMS evaluates the received messages and processes the 2-way commands, so other gateway activity of sending and receiving messages can continue while the 2-way commands are being processed.

The program thread that processes the 2-way commands processes only one message callback at a time, waiting for current 2-way command to complete before processing the next message.

If your 2-way command script is running on a web server on the same local network, and is reasonably quick in its processing, NowSMS can process approximately 100 messages per second for HTTP-based 2-way commands in ideal situations. However, not all configurations are ideal, and in typical configurations, NowSMS spends more time waiting for the 2-way command to complete than in the actual processing of the message. This waiting for the 2-way command has a significant impact on 2-way command message throughput.

It is possible to configure NowSMS to allocate more 2-way command processing threads to provide higher throughput by editing SMSGW.INI, and under the [SMSGW] section header, adding 2WaySMSThreadCount=## ... where ## is the number of threads to allocate.

In future versions of NowSMS, we will be enabling the use of HTTP keep-alive sockets, which our tests have shown can increase single threaded "ideal" throughput to a range of 175 to 200 messages per second processed by a single 2-way command. While that will offer some performance boost, typical configurations are not limited by the speed at which NowSMS processes 2-way commands, but rather by the speed at which actual 2-way command scripts perform their processing logic. For those typical configurations, allocating multiple 2-way command processing threads can offer a performance boost.

MMS MM7 SOAP Problems with Vodafone UK

2008-10-03T17:52:00.003Z

If you're trying to use NowSMS to interface with the Vodafone UK MMSC over MM7, you may be experiencing a problem where the Vodafone MMSC is reporting SOAP errors, indicating that the SOAP headers cannot be accessed.

This appears to be a bug in their MMSC. The Vodafone UK MMSC does not like the MIME boundary text that NowSMS generates. While the MIME boundary used by NowSMS correctly conforms to the specification, the choice of characters in the boundary appear to be causing a program error in this operator MMSC.

At this point, we're not sure which vendor MMSC Vodafone is using, or if perhaps it is a problematic piece of middleware, so this may affect other mobile operators that are using the same MMSC product.

An updated version of NowSMS contains a work-around for this problem, generating alternate text for the MIME boundary, which is acceptable to this MMSC. This update is applied for NowSMS v2008.10.01 and later versions. Currently this update is available for download at the following link: http://www.nowsms.com/download/nowsmsupdate.zip.

SMS Retry Error Handling with UCP/EMI and CIMD

2008-10-02T10:00:00.001Z

There's a great post that discusses how NowSMS handles message retries in SMPP environments at the following link: http://blog.nowsms.com/2007/06/smpp-error-code-handling-in-nowsms.html

However, to date, there hasn't been anything written that goes into as much detail regarding how NowSMS handles message retries in UCP/EMI or CIMD2 environments.

The short answer is that, by default, if NowSMS receives an error response from the SMSC when submitting a message in a UCP/EMI or CIMD2 environment, NowSMS will retry sending the message up to RetryMaxAttempts times (default=20).

The default behaviour for the delayed retry schedule works like this:

After the first error, a retry can be attempted immediately (but first NowSMS will try other pending messages in the outbound queue).

After the second error, NowSMS will wait 30 seconds before allowing the message to be retried.

After the third error, NowSMS will wait 60 seconds before allowing the message to be retried.

For each successive error, NowSMS waits an additional 30 seconds before allowing a retry. After 20 errors, the message will be considered as failed.

The following parameters can be applied to the [SMSGW] section of the SMSGW.INI file to provide additional control for the retry schedule:

RetryDelay=
RetryDelayMultiplier=
RetryDelayAfterAttempts=
RetryDelayMax=
RetryMaxAttempts=

The above parameters control retry behaviour for when NowSMS is submitting messages to an SMSC and an error occurs.

RetryDelay=#### specifies a number of seconds to wait to retry sending after an error condition, the default value is 30.

RetryDelayMultiplier=### specifies a multiplier to be applied for successive send failures, the default value is 1. For each failed attempt, the retry delay will be the product of RetryDelay*RetryDelayMultiplier*#FailedAttempts. To use a fixed retry delay of RetryDelay, specify RetryDelayMultiplier=0.

RetryDelayAfterAttempts=### specifies that the retry delay should only be applied after ### failed attempts, the default value is 2. NowSMS will immediately retry a failed message send until it has made RetryDelayAfterAttempts, after which it will apply a retry delay.

RetryMaxAttempts=### specifies the maximum number of retries that NowSMS will attempt before a message is rejected, the default value is 20.

That is all well and good, but in many situations, especially when you might be sending premium rate SMS to pre-pay users, your NowSMS message queues may become slow with numerous retry attempts sending to users with depleted credit balances.

Our standard recommendation has been to reduce the RetryMaxAttempts setting to a lower value. NowSMS only counts a message retry attempt when it encounters an error during a submit message operation. If instead, there is a situation where an SMSC connection is down, this does not count as a message retry attempt. (It does count as a retry attempt if the SMSC connection drops while NowSMS is attempting to submit a message.)

If you have a situation where you want NowSMS to consider certain error SMSC error codes to be a permanent error, with no retry attempt, it is possible to add these error codes to an SMSGW.INI file setting.

For SMPP connections, refer to the previous blog entry at http://blog.nowsms.com/2007/06/smpp-error-code-handling-in-nowsms.html.

For UCP/EMI and CIMD connections, the following configuration settings were added in NowSMS v2008.10.01 and later. (Until the next major release of NowSMS, an interim update to this version can be downloaded from http://www.nowsms.com/download/nowsmsupdate.zip.)

For UCP/EMI SMSC connections, under the [SMSGW] section header, add UCPRejectErrorCodes=x,y,z

This "x,y,z" value can be a comma-delimited list of decimal error codes that should be treated as permanent errors. Note that if you are experiencing excessive retry problems, you can see what error your provider is returning by consulting the SMSOUT-yyyymmdd.LOG file.

It is also possible to specify UCPRejectErrorCodes=All to cause any error codes returned by your provider as a permanent message delivery failure.

For CIMD2 SMSC connections, under the [SMSGW] section header, add CIMDRejectErrorCodes=x,y,z

This "x,y,z" value can be a comma-delimited list of decimal error codes that should be treated as permanent errors. Note that if you are experiencing excessive retry problems, you can see what error your provider is returning by consulting the SMSOUT-yyyymmdd.LOG file.

It is also possible to specify CIMDRejectErrorCodes=All to cause any error codes returned by your provider as a permanent message delivery failure.

SMPP Connection Types - Sender, Receiver, Transceiver

2008-07-28T07:35:00.000+01:00

When making a connection to an SMPP server, there are three different types of connections that can be supported.

A "sender", or "send only", connection is allowed to transmit messages only over the connection, it cannot receive any messages. (Some SMPP servers will still deliver SMPP delivery receipt messages over a "sender" connection.)

A "receiver", or "receive only", connection is not allowed to transmit messages over the connection, it can only receive messages. Any attempt to receive messages over this connection will usually result in the error ESME_RINVBNDSTS (Incorrect BIND Status for given command). If you see the ESME_RINVBNDSTS error when submitting messages, check to see that NowSMS has not been inadvertantly configured for a receiver only connection.

A "transceiver" connection is allowed to both send and transmit messages over the same connection.

When defining an SMPP connection in NowSMS, it is possible to configure the connection to be only a "sender", only a "receiver", separate "sender" and "receiver" connections, or a single "transceiver" connection.

The type of connection that you use will depend on the preferences and policies of your SMPP service provider. Separate "sender" and "receiver" connections generally offer the best performance under extreme loads, however your provider may wish for you to use a "transceiver" connection to reduce the connection overhead on their server.

There are also special configurations where you may need to configure a connection to be only a "sender", or only a "receiver".

To define a "sender" connection only, ensure that the following settings are applied in the properties for the SMPP connection:

"Receive SMS Messages" must not be checked.
Under "Advanced Settings", "Send and Receive Messages over the same connection" must not be checked.

To define a "receiver" connection only, ensure that the following settings are applied in the properties for the SMPP connection:

"Sender Address" should be left blank.
"Receive SMS Messages" must be checked.
"Support any outbound message traffic" must not be checked.
The "Preferred SMSC Connection for" list should be empty.
Under "Advanced Settings", "Send and Receive Messages over the same connection" must not be checked.

To define a connection with separate "sender" and "receiver" connections, ensure that the following settings are applied in the properties for the SMPP connection:

"Receive SMS Messages" must be checked.
Under "Advanced Settings", "Send and Receive Messages over the same connection" must not be checked.
Either "Support any outbound message traffic" must be checked, or there must be at least one entry in the "Preferred SMSC connection for" list.

The last setting may cause problems for configurations where you only want to route messages for sending via this connection explicitly (as described in "Routing SMS Messages to a Specific SMSC Route"). If you wish to only use explicit routing to route messages via this connection, add the text "explicit" to the "Preferred SMSC connection for" list, so the list will no longer be blank.

To define a "transceiver" connection, ensure that the following settings are applied in the properties for the SMPP connection:

"Receive SMS Messages" must be checked.
Under "Advanced Settings", "Send and Receive Messages over the same connection" must be checked.

MMS Message Retries, Expiration, Conversion to SMS

2008-07-14T19:04:00.000+01:00

There was a good simple question posted on the NowSMS Discussion Board.

We are using the MMS Gateway service. For how long does the MMS content
stays in the system?

Can we set a specific time for the message expiration?

We also use the option of converting the mms to SMS with web link. For
how long is the content stored in the platform?

As I replied to that question, I realized that there are a number of MMSC related settings that are important to operator MMSC configurations, but that are either not configurable via the NowSMS configuration user interface, or when they are, they are perhaps not very well explained.

So let me start by answering these specific questions, and then I want to expand a bit on some inter-relationship between the settings, and some other related settings.

By default, MMS mesasge content is retained for 15 days before it is expired.

To change this timeout, it is necessary to edit MMSC.INI, and under the [MMSC] section header, add DataRetainDays=##, where ## is the number of days for MMS message data to be retained by the system.

This same expiration timeout applies to messages that are converted from MMS to SMS.

A simple question, and a simple answer. Hardly worth a blog posting. However, it did get me thinking about a lot of the related configuration settings that perhaps some users don't understand.

MMS Notification Retries

The "How MMS Works" web page is a good reference for explaining the basics of how the MMS delivery process works.

To deliver an MMS message to a client, the MMSC sends an MMS Notification message with WAP Push (over SMS in most configurations). When the client receives the MMS Notification mesasge, the client then connects to the MMSC to retrieve the MMS message content and complete the MMS delivery process.

The default settings in NowSMS assumes that the WAP Push over SMS delivery is reliable. Only one notification attempt is performed, and it is assumed that the SMSC that is responsible for delivering these notifications will queue the messages for delivery until the client is available.

In some situations this may not be a safe assumption. In these instances, the MMSC can be configured to retry these notifications to increase the probability that the client will actually receive the notification. (MMS clients will ignore duplicate notifications.)

To enable these retries, check "Retry MMS Delivery Notification". Then specify the number of "Attempts" that the MMSC should make in retrying the MMS notification, as well as the "Delay" interval (in minutes) between attempts. Note that the MMSC will apply a progressive delay, increasing the delay with each attempt, such that the actual delay interval is the configured delay interval multiplied by the number of previous notification attempts. As an example, if "Attempts" is set to 4, and "Delay" is set to 15, the first retry attempt will occur after 15 minutes. The next attempt will occur after 30 minutes after the previous attempt, then 45 minutes after the previous attempt, then 60 minutes after the previous attempt, after which no further notifications will be attempted.

It is also possible to configure the MMSC such that it if an MMS message is not retrieved from the MMSC within a configurable timeout period, the MMSC will then convert the message to SMS, sending a text SMS message to the recipient, with a URL like that can be used from either a phone or PC browser, to retrieve the content of the message.

To enable this SMS conversion, it is necessary to define an "MMSC Routing" of the type "Convert to SMS web Web Link".

Once that routing is defined, edit MMSC.INI, and add the following settings under the [MMSC] header:

UndeliverableRouteToSMS=VASPOutboundRouteName

This setting specifies the name of an MMSC Outbound Route that is defined in the "MMSC Routing" list, which must be of the type "Convert to SMS with Web Link". By default, if an MMS message has not been retrieved within 120 minutes, the message will be rerouted to be sent as an SMS with a web link for accessing the MMS content.

UndeliverableRouteToSMSTimeout=####

#### is a value in minutes that changes the time period after which the UnderliverableRouteToSMS setting is applied.

Routing SMS messages to a Specifc SMSC Route

2008-07-10T14:13:00.002+01:00

If you need control over routing to particular SMSC connections, the logic in NowSMS works like this:

When NowSMS routes a message, it first looks to see if a sender address has been specified for the message submission (normally there is not a sender address specified, unless you submitted the message via HTTP and specified a "Sender=" parameter). If a sender address was specified, then NowSMS checks to see if the sender address matches the "Default Sender Address" that is configured for any of the SMSC links (or the "Phone Number" associated with a GSM modem). If NowSMS finds a match, then it will route the message only via an SMSC connection with a matching sender address.

(Note: It is possible for the "Default Sender Address" field to include a comma delimited list of phone/shortcode numbers, indicating that a message with a sender address that matches any of these numbers should be routed via the connection.)

If NowSMS did not find a match on the sender address, then it evaluates the recipient address, and it will look to see if it finds a match in the "Preferred SMSC Connection for" recipient address masks associated with any of the SMSC connections. (These recipient address masks can be wildcards such as "+44*" to match any phone number that starts with "+44".) If NowSMS finds a match, then it looks for the longest mask that provides a match, and routes the message via the connection with the longest matching mask. (For example, if you were sending to +447624999999, and you had one connection with a mask of "+44*", and another with "+447624*", then the connection with the mask of "+447624*" would be used as it is a longer match than "+44*".)

If there is no match on the recipient address mask, then the message will be routed via any connection that has "Support any outbound message traffic" checked.

(Note: It should also be mentioned that if NowSMS found multiple matches on the sender address, it evaluates the "Preferred SMSC Connection for" recipient address masks for each of the connections that had a sender address match.)

There is also an additional HTTP parameter setting that can be used to explicitly route a message via a particular SMSC, so that you don't have to use the sender/recipient matching logic if it is not appropriate for your configuration.

This additional HTTP parameter works like this:

When you submit a message via HTTP, the HTTP interface supports "&SMSCRoute=xxxxx", where the value of this setting can be the name of a defined SMSC (e.g., "Bluetooth Modem" or "SMPP - a.b.c.d:xyz"). Or, rather than using the SMSC name, it can be a route name that is defined as associated with an SMSC. To define a route name for an SMSC, it is necessary to manually edit SMSGW.INI, and under the appropriate section header (e.g., [Modem - Bluetooth Modem] or [SMPP - a.b.c.d:xyz]), add RouteName=xxxxx. It is possible for multiple SMSCs to share the same route name, meaning that if a message is submitted with "&SMSCRoute=xxxxx", it will be routed outbound over the first available SMSC that is configured with RouteName=xxxxx.

With mobile number portability (MNP), it can be difficult to determine the mobile operator to which any given phone number belongs. If mobile subscribers initiate their subscription to your service by sending an SMS to your short code, it may be useful for your service to remember the SMSC route from which the message was received. This way, you can be sure to route any future messages to that subscriber via the same SMSC connection. If you use the 2-way command functionality in NowSMS, include an @@SMSCROUTE@@ parameter in your 2-way command, and NowSMS will insert the received "RouteName" into this parameter value. More information on this topic can be found in the posting titled 2-way SMS: Multiple operators with the same shortcode.

One WAP Gateway for both MMS and Browser Data

2008-07-07T09:30:00.000+01:00

Smaller mobile operators often ask us how to deploy a single WAP Gateway (or WAP Proxy if you prefer that terminology, as our marketing folks seem to prefer) to deploy both MMS traffic and general browser traffic.

Of course, technically there is no reason that a single WAP Gateway can't support both types of traffic. So if you're not a mobile operator, you're probably wondering what the point of this posting is.

In most environments, the mobile operator does not charge for data that is transferred to and from the MMSC. This MMS data is simply considered to be a part of the charge for sending or recieiving the MMS message, as it is difficult to explain to a user that they are charged both for the message and the related data traffic.

However, other non-MMS data traffic is considered chargeable.

The way that this is normally implemented is that at least two different APNs are deployed on the GPRS/EDGE/WCDMA network. One APN is for for MMS data traffic only, and another is for browsing data traffic. (Additional APNs might support general internet traffic, or the general internet traffic might use the browsing APN.)

When a user connects to the MMS APN, they should only be allowed to communicate with the MMSC.

If the same WAP Gateway is to be used for both MMS and browsing data traffic, how does the WAP Gateway know whether or not to limit access?

There are two ways that this can be configured using the NowWAP 2008 release.

I would stress that this solution is only recommended for smaller to small/medium sized operators where there is insufficient data traffic to warrant multiple WAP gateways.

As part of a contingency plan to allow for future growth, the first recommendation that we would make is that even though both services will be sharing the same WAP gateway, the mobile phone settings for your subscribers should have different IP addresses for the WAP gateway configured in the mobile phone settings for MMS or web browsing. It is an easy task to provision multiple IP addresses on the server that is running the WAP gateway, and we strongly recommend that this be done. If your traffic grows in the future, it will then make it a simpler task to migrate to separate WAP gateways for MMS and browsing traffic.

Within NowWAP, it is possible to limit certain client connections so that they are only able to connect to the host/domain names that are listed in the "Content Domains to receive X-MSISDN header" setting on the MSISDN page of the NowWAP configuration.

This setting is primarily used for determing which hosts should receive the "X-MSIDN:" header, which contains the phone number of the user making the request.

As a refresher, here is the description of this setting from the NowWAP documentation:

When a content domain is added to this list, a host name that exactly matches the content domain, as well as any host names within the content domain will receive the “X-MSISDN:” header. For example, if “now.co.uk” is added to the content domain list, the “X-MSISDN:” header would be forwarded to a host named “now.co.uk” as well as for “www.now.co.uk” and “mms.now.co.uk”. If you wish to have the “X-MSISDN” header forwarded to all content servers, define a content domain named “*”.

Within NowWAP, it is then possible to specify that certain client connections should only be allowed to connect to hosts/domains that are in this list. And obviously, the MMSC needs to be in this list in order to receive MSISDN information, as this is how that information is supplied to the MMSC.

To configure that all client connections should only be allowed to connect to hosts/domains in this list, edit WAPGW.INI and under the [WAPGW] header, add IncludeMsisdnConnectOnly=Yes.

Obviously, the above setting will only work for an MMS-only proxy, as it would otherwise be too restrictive.

However, it is also possible to selectively restrict a connection to hosts/domains in this list based upon one of the following criteria:

1.) Restriction based upon Multi-Homed Gateway IP Address

This is best described with an example.

Let's say that the MMS-only APN gives out IP addresses on the 192.168.0.0 network.

The other APN, for browser traffic, gives out IP addresses on the 10.10.0.0 network.

The same WAP gateway is being used, the server operating system configured to be multi-homed on multiple networks.

Server address 10.10.0.1 would serve the browser network, and 192.168.0.1 would serve the MMS only network.

By adding IncludeMsisdnConnectOnlyGWIP=192.168.0.1 to the [WAPGW] section of the WAPGW.INI file, this would tell the WAP gateway that for any requests received by the server on 192.168.0.1, the gateway should only allow connections to domains/hosts in the "X-MSIDN" list. Connections to the gateway on other server addresses would not be restricted.

In order to make this solution work, it must not be possible (via firewall or networking setup) for any clients on the 192.168.0.0 network to connect to the WAP gateway on 10.10.0.1.

2.) Restriction based upon Client IP Address

This is, again, best described with an example.

Let's say that the MMS-only APN gives out IP addresses on the 192.168.0.0 network.

The other APN, for browser traffic, gives out IP addresses on the 10.10.0.0 network.

The same WAP gateway is being used, the server operating system may be configured to be multi-homed on multiple networks (this is not required, but recommended to allow for possible separation of MMS and browser traffic in the future).

By adding IncludeMsisdnConnectOnlySourceIP=10.10.*.* to the [WAPGW] section of the WAPGW.INI file, this would tell the WAP gateway that for any requests that come from clients in that IP address range, the gateway should only allow connections to domains/hosts in the "X-MSIDN" list. Connections to the gateway from other client addresses would not be restricted. This setting can have a comma delimited list of IP addresses (e.g., 10.10.*.*,10,11.*.*). It does not support net masks ... it can only use the "*" character as a wildcard in parts of the IP address.

GSM Modem CMS Error Code List

2008-07-01T08:00:00.000+01:00

When sending and/or receiving SMS messages with a GSM modem, if an error occurs, the modem will report a "+CMS ERROR" with a numeric code to indicate the reason for the problem. These error codes are defined in the ETSI GSM specifications, specifically GSM 07.05, GSM 03.40 and GSM 04.11.

I posted a list of CMS ERROR codes on the NowSMS discussion board almost 5 years ago at http://www.nowsms.com/discus/messages/1/829.html.

It's a useful reference that I seem to search for a few times every month, so to make the information easier to find, I figured I would post it here.

Before I get to the list, and the sometimes cryptic definitions defined in the specifications, I want to highlight a few of the error codes that seem to occur most frequently.

+CMS ERROR 500 is probably the most commonly observed error code. The specifications define this as "unknown error". So, of course, that is the error code that many modems return for almost any reason. Most frequently, it seems that this error occurs when the modem simply does not have a signal, or it has too weak of a signal. It's a good idea to check the signal strength of the modem, and possibly relocate the modem so that it can acquire a stronger signal from the mobile operator.

+CMS ERROR 500 can also occur in situations where the mobile operator does not have SMS over GPRS (or SMS over 3G packet data) enabled. The default behaviour with most dedicated GSM modem devices is to try to send SMS over the packet network, and if this fails, fallback to the circuit switched network. However, in some environments, the modem doesn't know how to interpret the failure, and the fallback does not occur properly. To determine if this is the problem, try going into "Properties" for the modem in the "SMSC" list of NowSMS, and change "SMS Access" to "GSM".

+CMS ERROR 330 occurs frequently with 3G modems, it means that the address of the operator SMSC is not defined. It seems to be a bug in commonly used modem chipsets, where they do not read this address automatically from the SIM. To resolve this error, you need to manually define the operator SMSC address in the NowSMS configuration.

You can set the SMSC address by manually editing the SMSGW.INI file. Under the section header for the modem configuration (e.g., [Modem - ...], add SMSC=+phonenumber, where "+phonenumber" is the address of the SMSC. The best way to find this SMSC address is to move the SIM card from the modem temporarily to a phone, and go through the SMS configuration menus on the phone to determine the currently configured SMSC number. When you enter the SMSC phone number, always start it with a "+" and don't include any other non-numeric characters (no dashes or dots) in the address.

Always restart the gateway service after making a change to the SMSGW.INI file.

If you try setting the SMSC value by manually editing SMSGW.INI ... if the setting doesn't make a difference, always go back in and remove it immediately so that it doesn't confuse things down the road.

+CMS ERROR 304 occurs frequently when using Motorola phones as a modem. Basically, these modems have a bug that prevent them from being able to send any messages that include UDH (User Data Header). This includes almost all types of binary messages, as well as long text messages. There is no resolution for this problem, other than to use a different modem that does not suffer from this bug.

+CMS ERROR 512 is defined as a manufacturer specific error. From what we've seen, when this error occurs, it is usually the same as error 500.

General Troubleshooting Tips

Before I get into the full CMS ERROR code list, it may be worth offering some general troubleshooting tips, as the error codes themselves are usually quite cryptic.

In the "SMSC" list, highlight the modem and press "Properties". Try changing the "SMS Access" to "GSM".
Remove the SIM card from the modem, and put it into a mobile phone. Verify that you can actually send SMS messages using the SMS client in the mobile phone. If you cannot, then there may be a problem with your account with the mobile operator. (Note: We have observed that with some mobile operators, if you buy a modem with a SIM card, they assume that the modem is going to be used for internet access, and SMS capabilities are not provisioned for the account.)
Check the signal strength of the modem. Connect to the modem using HyperTerminal, and issue the command AT+CSQ. This will return a result in the format +CSQ: xx,yy. If the xx value is 99 (no signal), or lower than 10, you may have a signal problem. It's subjective, but I like to see this value as at least 16.

CMS ERROR Code List

1 - "Unassigned (unallocated) number"
This cause indicates that the destination requested by the Mobile Station cannot be reached because, although the number is in a valid format, it is not currently assigned (allocated).

8 - "Operator determined barring"
This cause indicates that the MS has tried to send a mobile originating short message when the MS's network operator or service provider has forbidden such transactions.

10 - "Call barred"
This cause indicates that the outgoing call barred service applies to the short message service for the called destination.

17 - "Network failure".
This cause is sent to the MS if the MSC cannot service an MS generated request because of PLMN failures, e.g. problems in MAP.

21 - "Short message transfer rejected"
This cause indicates that the equipment sending this cause does not wish to accept this short message, although it could have accepted the short message since the equipment sending this cause is neither busy nor incompatible.

22 - "Congestion".
This cause is sent if the service request cannot be actioned because of congestion (e.g. no channel, facility busy/congested etc.).

22 - "Memory capacity exceeded".
This cause indicates that the mobile station cannot store the incoming short message due to lack of storage capacity.

Note that error "22" is defined twice. It is likely that "CMS ERROR 22" would be due to the first definition, while the second definition is likely to only be a status code for delivery reports.

27 - "Destination out of service"
This cause indicates that the destination indicated by the Mobile Station cannot be reached because the interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a signalling message was unable to be delivered to the remote user; e.g., a physical layer or data link layer failure at the remote user, user equipment off-line, etc.

28 - "Unidentified subscriber"
This cause indicates that the subscriber is not registered in the PLMN (i.e. IMSI not known).

29 - "Facility rejected"
This cause indicates that the facility requested by the Mobile Station is not supported by the PLMN.

30 - "Unknown subscriber"
This cause indicates that the subscriber is not registered in the HLR (i.e. IMSI or directory number is not allocated to a subscriber).

38 - "Network out of order"
This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time; e.g., immediately reattempting the short message transfer is not likely to be successful.

41 - "Temporary failure"
This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g., the Mobile Station may wish to try another short message transfer attempt almost immediately.

42 - "Congestion"
This cause indicates that the short message service cannot be serviced because of high traffic.

47 - "Resources unavailable, unspecified"
This cause is used to report a resource unavailable event only when no other cause applies.

50 - "Requested facility not subscribed"
This cause indicates that the requested short message service could not be provided by the network because the user has not completed the necessary administrative arrangements with its supporting networks.

69 - "Requested facility not implemented"
This cause indicates that the network is unable to provide the requested short message service.

81 - "Invalid short message transfer reference value"
This cause indicates that the equipment sending this cause has received a message with a short message reference which is not currently in use on the MS-network interface.

95 - "Invalid message, unspecified"
This cause is used to report an invalid message event only when no other cause in the invalid message class applies.

96 - "Invalid mandatory information"
This cause indicates that the equipment sending this cause has received a message where a mandatory information element is missing and/or has a content error (the two cases are indistinguishable).

97 - "Message type non-existent or not implemented"
This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined or defined but not implemented by the equipment sending this cause.

98 - "Message not compatible with short message protocol state"
This cause indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the short message transfer state.

99 - "Information element non-existent or not implemented"
This cause indicates that the equipment sending this cause has received a message which includes information elements not recognized because the information element identifier is not defined or it is defined but not implemented by the equipment sending the cause. However, the information element is not required to be present in the message in order for the equipment sending the cause to process the message.

111 - "Protocol error, unspecified"
This cause is used to report a protocol error event only when no other cause applies.

127 - "Interworking, unspecified"
This cause indicates that there has been interworking with a network which does not provide causes for actions it takes; thus, the precise cause for a message which is being send cannot be ascertained.

0...127 - Other values in this range are reserved, defined by GSM 04.11 Annex E-2 values

128 - Telematic interworking not supported x
129 - Short message Type 0 not supported x x
130 - Cannot replace short message x x
143 - Unspecified TP-PID error x x
144 - Data coding scheme (alphabet) not supported x
145 - Message class not supported x
159 - Unspecified TP-DCS error x x
160 - Command cannot be actioned x
161 - Command unsupported x
175 - Unspecified TP-Command error x
176 - TPDU not supported x x
192 - SC busy x
193 - No SC subscription x
194 - SC system failure x
195 - Invalid SME address x
196 - Destination SME barred x
197 - SM Rejected-Duplicate SM x
198 - TP-VPF not supported X
199 - TP-VP not supported X
208 - SIM SMS storage full x
209 - No SMS storage capability in SIM x
210 - Error in MS x
211 - Memory Capacity Exceeded X
212 - SIM Application Toolkit Busy x x
255 - Unspecified error cause

128...255 - Other values in this range are reserved, defined by GSM 03.40 subclause 9.2.3.22 values

300 - ME failure
301 - SMS service of ME reserved
302 - operation not allowed
303 - operation not supported
304 - invalid PDU mode parameter
305 - invalid text mode parameter
310 - SIM not inserted
311 - SIM PIN required
312 - PH-SIM PIN required
313 - SIM failure
314 - SIM busy
315 - SIM wrong
316 - SIM PUK required
317 - SIM PIN2 required
318 - SIM PUK2 required
320 - memory failure
321 - invalid memory index
322 - memory full
330 - SMSC address unknown
331 - no network service
332 - network timeout
340 - no +CNMA acknowledgement expected
500 - unknown error

256...511 - Other values in this range are reserved

512... - manufacturer specific

SMSC Speed Limits

2008-06-26T14:58:00.000+01:00

In a perfect world, we'd all be able to send SMS messages as fast as we wanted.

But the reality is that there is a combination of commercial and technical limitations throughout the message distribution chain.

NowSMS has commercial limitations where outbound message delivery is throttled at a per minute or per second license limit.

Individual SMS service providers have similar limits that they impose.

When you have a single SMS service provider connection, it is often easiest to match a NowSMS license limit with the license limit of your SMS service provider connection.

But sometimes this speed limit matching isn't a perfect match.

For example, if your NowSMS system is connecting to multiple SMSC providers, NowSMS may try to send messages to one or more of your SMSC connections which exceeds the limit imposed by your SMS service provider.

What happens when you exceed the speed limit imposed by your SMS service provider?

It depends. There is no single answer, because there are a lot of different software implementations used by different SMS service providers.

In some cases, no problems occur. If the SMS service provider throttles back the speed at which it returns responses to NowSMS, NowSMS automatically slows down the connection to the speed desired by the service provider. (If you define an SMPP async window size that is too large, however, you may end up with retry errors and duplicate messages in this situation. A good rule of thumb is that the SMPP async window size should not exceed 2, or maybe 3, times the number of messages per second that the connection will accept.)

In other cases, the SMSC starts returning throttling errors, the dreaded ESME_RTHROTTLED. But throttling errors can occur for different reasons. They could also occur because the overall SMS system message queue is too large, and the provider needs all customers to slow down to give the system some time to catch up. By default, a throttling error causes NowSMS to have to retry the current message, and to wait 5 seconds before submitting the next message.

5 seconds is a long time to wait for sending the next message if you're exceeding a 10 message per second limit. However, the default throttling delay of 5 seconds exists because when you're connecting directly to a mobile operator, most of these mobile operators have acceptance testing procedures where they test your connection before allowing you to connect to their system. And one of the tests is always the handling of the throttling error, where historically they have wanted to see longer delays.

This throttle error delay can be adjusted by editing SMSGW.INI, and under the [SMSGW] section header, adding SMPPThrottleErrorDelay=##, where ## is a number of seconds to delay. SMPPThrottleErrorDelay=0 will remove any delay.

If you are receiving throttling errors, or possibly other error conditions, because you are exceeding the provider imposed speed limit of your SMSC connection, the best solution is to configure NowSMS to apply this speed limit to that particular SMSC connection.

It is possible to manually edit the SMSGW.INI file, and under the settings header for a particular SMSC connection (e.g., [SMPP - server:port]), use the following setting to define a speed limit for that connection only using the SMSCSendLimit=x/y setting.

The SMSCSendLimit=x/y setting can specify that the gateway will send no more than x
messages per y seconds. If y is not specified, then the default is 1. For example, to limit a
connection to 1 message every 5 seconds, specify SMSCSendLimit=1/5. To limit a
connection to 3 messages per second, specify SMSCSendLimit=3 or SMSCSendLimit=3/1.

In versions of NowSMS prior to v2008.06.03, this setting did not work very well for limits higher than around 50 messages per second. However, in more recent versions of NowSMS, this setting works well for speed limits higher than 50 messages per second.

While on the subject of SMSC speed limits, it is also worth mentioning that when NowSMS is used as an SMPP server, it can apply speed limits against the accounts that are submitting messages via SMPP (but not HTTP). When defining an "SMS Users" account, there is a setting to "Limit Speed of receiving messages for this account" which uses a similar "x messages / y seconds" type of definition.

It is also worth mentioning that this "SMS Users" account setting can also limit the number of SMPP connections that the client is allowed to make. Under the "SMPP Options" on the "Web" page of the NowSMS configuration, there is a system default limit for defining the maximum number of connections per individual client. However, this setting can be overridden on a per-account basis using the "Limit speed of receiving messages for this account" setting. In the "# Messages/# Seconds" field, enter a value of x/y/z, where "x" is the number of messages allowed per "y" seconds, and "z" is the connection limit to be applied for this account. To disable message speed limits, but define a connection limit, use a value of 0/0/z, which indicates no limits, but specifies "z" as the connection limit for this account.