MMS Conversion to SMS With Web Link

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

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

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

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

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

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)

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

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

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.