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.

SMPP Connection Types - Sender, Receiver, Transceiver

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:

1. "Receive SMS Messages" must not be checked.
2. 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:

1. "Sender Address" should be left blank.
2. "Receive SMS Messages" must be checked.
3. "Support any outbound message traffic" must not be checked.
4. The "Preferred SMSC Connection for" list should be empty.
5. 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:

1. "Receive SMS Messages" must be checked.
2. Under "Advanced Settings", "Send and Receive Messages over the same connection" must not be checked.
3. 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:

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

MMS Message Retries, Expiration, Conversion to SMS

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

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.