There are other articles that explain how NowSMS handles retry situations for outbound message delivery.  A good overview can be found in the article SMPP Error Code Handling in NowSMS.  While that article focuses primarily on SMPP connections, the general parameters do also apply to modems.  Additional issues specific to CIMD2 and UCP/EMI SMSC connections can be found in the article SMS Retry Error Handling with UCP/EMI and CIMD2.

There are two types of error conditions to consider.   One condition is that the 2-way command is unable to process a message and returns an error response, such as “500 Internal Error”.  This could happen because of a web server configuration problem, or it could also happen because of a logic error in the 2-way command … for example, it is not uncommon to find programming errors in a 2-way command where unexpected message content causes unexpected problems.  The other type of condition, is a connectivity problem where it is not possible to connect to the web server hosting the 2-way command.

If a web server returns a valid HTTP error response, such as “500 Internal Error”, NowSMS policy is to mark the message as bad and never retry the message.  Over 5 years ago, older versions of NowSMS used to retry messages in these situations, but customers who encountered script problems complained about duplicate messages when their scripts returned unexpected errors.   When a message in the 2-way SMS queue fails in this manner, a file with a .BAD file extension is created inside the NowSMS\SMS-IN directory structure.  It is  possible to rename the file with a .IN file extension to trigger NowSMS to reprocess the message.

The remainder of this document explains retry procedures for messages where it is not possible to connect to the web server hosting the 2-way command, or the web server does not return a valid HTTP response (timeout).

By default, NowSMS will retry 20 times with a staggered delay based upon the number of previous failures.

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).

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 [2Way] section of the SMSGW.INI file to provide additional control for this retry schedule (this section of the file will not exist until you create it):

RetryDelay=
RetryDelayMultiplier=
RetryDelayAfterAttempts=
RetryDelayMax=
RetryMaxAttempts=

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.

RetryDelayMax=### specifies the maximum number of seconds that NowSMS will allow to elapse between retries, putting a limit on the multiplier.

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

Note: If memory serves me correctly, the default values will result in about 90 minutes worth of retries before erroring out. (And the message file being renamed with a .BAD extension.)

Note that if these same settings names are also used to control retry behaviour for outbound messages.

Retry settings set under the [SMSGW] section header will apply to both inbound (2-way) and outbound messages.  If retry settings exist under both [2Way] and [SMSGW], [2Way] settings are used for inbound (2-way) messages and [SMSGW] settings are used for outbound messages.

Retry settings can also be placed under connection specific headers (e.g., [Modem - xxx] or [SMPP - server:port]) so that different rules can apply to different outbound connections.

These accounting callbacks are HTTP-based. When accounting callbacks are enabled, NowSMS will issue HTTP requests to a customer supplied URL in order to interface with the customer billing and charging systems.

To enable SMS accounting callbacks, it is necessary to manually edit the SMSGW.INI configuration file, and define the callback URL under the [SMSGW] section header, using the following configuration parameter:

SMSAccountingURL=http://server/path

Whenever the SMS Gateway processes an SMS message, it issues an accounting callback by issuing an HTTP transaction to the callback URL. Variables describing the SMS message transaction are appended to the SMSAccoutingURL as HTTP GET CGI-style variables, with standard URL escaping applied for encoding reserved characters.

For example:

http://server.name/path?PreAuth=Yes&Type=SMSSend&From=UserAccount&To=%2B447777777777
&MsgCount=1&SubmitIP=127.0.0.1&Text=This%20is%20a%20test.

(These variables and transaction types will be described later in this section.)

Accounting callbacks exist primarily to record billing and charging information, however they also can offer the ability to maintain credit control external to NowSMS.

The following accounting callbacks exist for SMS Messaging:

• SMSSend PreAuth Callback – This callback occurs when a client user account is attempting to submit an SMS message to NowSMS.  The callback can choose to accept or reject the message, and can optionally control message routing and some other message attributes.
• SMSSend Accounting Callback – This callback occurs when a client user account has submitted an SMS message to NowSMS, and NowSMS has accepted this message for processing.  The callback can choose to accept or reject the message, and can optionally control message routing and some other message attributes.
• SMSOut Accounting Callback – This callback records that a message has been submitted to an upstream SMSC connection, or has an encountered an error condition or rejection when attempting to be sent to an upstream SMSC connection.
• SMSIn Accounting Callback – This callback records that an inbound message has been received from an upstream SMSC connection.

The remainder of this section provides additional details on the parameters supported by these callbacks.

SMSSend PreAuth Callback

This callback is executed when an SMS (web, SMPP, SMTP) user is requesting to send a message.

This is a “pre-authorisation” request, and does not mean that the message will actually be accepted by NowSMS for delivery. If NowSMS cannot successfully connect to the accounting URL, or the URL returns a response other than a standard “HTTP 200 OK” response, the user request to send a message will be blocked.  To separate error conditions from active blocking of a message, we recommend that the response include the text “PreAuth=Deny” if the message should be blocked from acceptance.

HTTP clients can submit a single message to multiple recipients.  In this case, normal behaviour for NowSMS is to use a single PreAuth callback specifying the  number of messages that will be sent in the “MsgCount” parameter.  It is possible to override this behaviour and generate a separate PreAuth callback per recipient by setting SMSAccountingPreAuthPerRecip=Yes under the [SMSGW] section header of SMSGW.INI.  (The setting SMSAccountingMustSetRoute=Yes also forces this per recipient callback behaviour.)  If a PreAuth callback rejects one recipient of a multiple recipient message, the entire message will be rejected.  For this reason, it is important to understand that a successful PreAuth callback does not mean that NowSMS has accepted a message for processing.  NowSMS will generate a separate SMSSend Accounting Callback (always one per recipient) when it accepts the message for further processing.

The following variables will be set for a pre-authorisation request:

PreAuth=Yes (indicates that the message is a Pre-Authorisation Request)
Type=SMSSend
From=Defined “SMS Users” Account
To=Comma delimited list of message recipients (will not be present if message is addressed to more than 100 recipients)
MsgCount=#### (number of recipients user is requesting to send the message to)
SubmitIP=a.b.c.d
SMSCRoute=xxxxxx (optional, will be present only if an explicit route was requested in message submission)
Sender=xxxxxx (optional, will be present only if a sender address was specified in message submission)
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
ReceiptRequested=Yes (optional, will be present only if message is requesting a delivery receipt … only available in v2009.01.26 and later)

Any defined SMPPOption parameters will also be included.

(Note: For SMTP message submissions, only PreAuth, Type, From, To and MsgCount variables will be present.)

Example:

http://server.name/path?PreAuth=Yes&Type=SMSSend&From=UserAccount&To=%2B447777777777&MsgCount=1&SubmitIP=127.0.0.1&Text=This%20is%20a%20test.

Note that URL escaping is performed when building the URL string. Most HTTP scripting languages will automatically unescape these parameters for you (e.g., %2B is translated back to “+” and %20 is translated back to a space character).

The HTTP response can include additional text responses to further control message processing.  These additional responses are expected to appear in the text of the HTTP response, as Name=Value entries appearing with one Name=Value per line of text (e.g., separated by new line characters).

The following Name=Value responses are supported for the SMSSend PreAuth Callback:

PreAuth=Deny

This causes NowSMS to reject the message, and the submitting client will receive a submission error.

SMPPErrorCode=0x#### or ####

Specifies a numeric error code to be returned to the submitting client if the message was submitted via SMPP.  The default error code for a rejected message is 0×0058 (ESME_RTHROTTLED).

RejectMessage=text string

This parameter specifies error text to be returned to the user if the submission interface supports returning such text (e.g., HTTP).

The following Name=Value responses are supported only if SMSAccountingPreAuthPerRecip=Yes or SMSAccountingMustSetRoute=Yes is set under the [SMSGW] section header of SMSGW.INI:

SMSCRoute=routename

If this setting is present in the response, NowSMS will use the specified outbound route name for delivering the message.   (For more information on SMS message routing, see http://www.nowsms.com/routing-sms-messages-to-a-specifc-smsc-route.)  In NowSMS versions 2011.08.11 and later, the SMSCRoute can also take the format localuser:username (the text localuser: followed by a user account name) to indicate that the message should be routed to a local user account instead of an outbound SMSC connection.

Note:  If you are relying on accounting callbacks to set route information, we recommend setting SMSAccountingMustSetRoute=Yes under the [SMSGW] section header of SMSGW.INI.  If this setting is not present, and an accounting callback returns invalid or missing routing information, NowSMS will use its internal routing logic to route the message.   If this setting is present, NowSMS will reject or fail messages if the accounting callback returns invalid or missing routing information.

Further Note:  Routing information can be returned in response to either the SMSSend PreAuth or SMSSend Accounting Callbacks.  If set by the SMSSend PreAuth Callback, any routing response by the SMSSend Accounting Callback will  be ignored and the PreAuth routing information will be used.

RouteCharge=####

If NowSMS credit balances are being used for user accounts, this specifies a charge to be used for the message.  By default, NowSMS assumes 1 credit per message.  This value can support a variable number of credits, including decimal values valid to thousandths of a credit (e.g., .001).

UserData=text

If this value is returned, it will be passed as a parameter to any future SMSSend Accounting Callback referencing this same transaction.  NowSMS versions 2012.02.09 and later will also pass this parameter to any future SMSOut Accounting Callback referencing this same transaction.

SMSSend Accounting Callback

This callback is executed after an SMS message that has been submitted by a client user account has been accepted by NowSMS for further processing.

In NowSMS 2009 and later, NowSMS will check the response to the HTTP request. If this response includes the text “SMSCRoute=xxxxx”, then NowSMS will apply this SMSC route for the message. The specified route “xxxxx” can either be the name of a particular SMSC connection (e.g., “SMPP – host:port”), or it can be the value of the “RouteName=” attribute defined for one or more connections. (For more information on the “RouteName=” attribute, see http://www.nowsms.com/routing-sms-messages-to-a-specifc-smsc-route.)

In NowSMS versions 2011.08.11 and later, the SMSCRoute can also take the format localuser:username (the text localuser: followed by a user account name) to indicate that the message should be routed to a local user account instead of an outbound SMSC connection.

Note:  If you are relying on accounting callbacks to set route information, we recommend setting SMSAccountingMustSetRoute=Yes under the [SMSGW] section header of SMSGW.INI.  If this setting is not present, and an accounting callback returns invalid or missing routing information, NowSMS will use its internal routing logic to route the message.   If this setting is present, NowSMS will reject or fail messages if the accounting callback returns invalid or missing routing information.

The following variables will be set for the accounting callback:

Type=SMSSend
From=Defined “SMS Users” Account
To=Message Recipient Phone Number (if the message is sent to multiple recipients, this callback is repeated for each recipient)
MessageID=Message ID assigned to the message by NowSMS
SubmitIP=a.b.c.d
SMSCRoute=xxxxxx (optional, will be present only if an explicit route was requested in message submission)
Sender=xxxxxx (optional, will be present only if a sender address was specified in message submission)
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
ReceiptRequested=Yes (optional, will be present only if message is requesting a delivery receipt … only available in v2009.01.26 and later)

Any defined SMPPOption parameters will also be included.

(Note: For SMTP message submissions, only Type, From, and To variables will be present.)

Example:

http://server.name/path?Type=SMSSend&From=UserAccount&To=%2B447777777777&SubmitIP=127.0.0.1&Text=This%20is%20a%20test.

Note that URL escaping is performed when building the URL string. Most HTTP scripting languages will automatically unescape these parameters for you (e.g., %2B is translated back to “+” and %20 is translated back to a space character).

The HTTP response can include additional text responses to further control message processing.  These additional responses are expected to appear in the text of the HTTP response, as Name=Value entries appearing with one Name=Value per line of text (e.g., separated by new line characters).

The following Name=Value responses are supported for the SMSSend Accounting callback:

SMSCRoute=routename

If this setting is present in the response, NowSMS will use the specified outbound route name for delivering the message.   (For more information on SMS message routing, see http://www.nowsms.com/routing-sms-messages-to-a-specifc-smsc-route.)  In NowSMS versions 2011.08.11 and later, the SMSCRoute can also take the format localuser:username (the text localuser: followed by a user account name) to indicate that the message should be routed to a local user account instead of an outbound SMSC connection.

Note:  If you are relying on accounting callbacks to set route information, we recommend setting SMSAccountingMustSetRoute=Yes under the [SMSGW] section header of SMSGW.INI.  If this setting is not present, and an accounting callback returns invalid or missing routing information, NowSMS will use its internal routing logic to route the message.   If this setting is present, NowSMS will reject or fail messages if the accounting callback returns invalid or missing routing information.

Further Note:  Routing information can be returned in response to either the SMSSend PreAuth or SMSSend Accounting Callbacks.  If set by the SMSSend PreAuth Callback, any routing response by the SMSSend Accounting Callback will  be ignored and the PreAuth routing information will be used.

UserData=text

If this value is returned, NowSMS versions 2012.02.09 and later will also pass this parameter to any future SMSOut Accounting Callback referencing this same transaction.

SMSOut Accounting Callback

This callback is executed when a submitted SMS message is dispatched to an upstream SMSC connection, or queued for a local SMPP user account.

The response to this HTTP callback is currently ignored. A standard HTTP 200 OK response is encouraged for future compatibility.

The following variables can be set for the accounting callback:

Type=SMSOut
From=String (local user account name, or upstream SMSC connection name)
To=Message Recipient Phone Number
MessageID=Message ID assigned to the message by NowSMS
SubmitIP=a.b.c.d (not present for messages received from upstream SMSC connection)
Sender=xxxxxx
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
MessageID=String (NowSMS assigned message ID)
SMSCMsgId=String (upstream SMSC assigned message ID, if available)
SMSCName=String (the SMSC connection to which this message was routed in the format that it appears in the NowSMS SMSC list, e.g., “SMPP – servername:port”)
Status=String (Starts with “OK”, “Retry Pending” or “ERROR” to indicate message disposition)

Any defined SMPPOption parameters will also be included.

SMSIn Accounting Callback

This callback is executed when an SMS message is received from an upstream SMSC connection.

The response to this HTTP callback is currently ignored. A standard HTTP 200 OK response is encouraged for future compatibility.

The following variables can be set for the accounting callback:

Type=SMSIN
To=Message Recipient Phone Number
Sender=xxxxxx
Binary=1 (optional, will be present if the message is binary)
PID=# (optional, will be present only if a non-zero PID value was specified in message submission)
DCS=# (optional, will be present only if a non-zero DCS value was specified in message submission)
UDH=HexString (optional, will be present only if message contains User Data Header)
Data=HexString (optional, will be present only if message is binary)
Text=String (optional, will be present only if message is text)
SMSCReceiptMsgID=String (optional, NowSMS assigned message ID will be present if this is a delivery receipt)
SMSCReceiptMsgIDOrig=String (optional, upstream SMSC assigned message ID will be present if this is a delivery receipt)
SMSCName=String (the SMSC connection from which this message was received in the format that it appears in the NowSMS SMSC list, e.g., “SMPP – servername:port”)

Any defined SMPPOption parameters will also be included.

The purpose of this article is to document additional parameters supported in more recent versions of NowSMS.

This provisioning interface is enabled whenever one or more user accounts is defined in NowSMS under “SMS Users” with the “Enable Admin Access” checked.

This interface is accessed via the NowSMS web interface port, with a URI of “/provision” followed by a series of “HTTP GET” parameters. (The admin username and password must be supplied in the HTTP GET request within an “Authorization:” header using HTTP Basic Authentication, or they can be be appended to the URL as parameters such as /provision?user=username&password=password.  Using URL parameters for provisioning authentication is supported only in NowSMS 2012.01.10 and later.)

Two different provisioning request formats are defined, one for defining ”SMS Users” accounts, and a second for defining “MMSC Users” accounts.

If a parameter of ”Type=SMS“ is specified, the following parameters are supported:

AdminAction=Add, Modify, Delete, or CreditCheck

Name=Account Name

Password=password

Fullname=Full Name

EnableWebLogin=Yes/No

EnableSmppLogin=Yes/No

EnableSmtpLogin=Yes/No

ForcedSenderAddress=Sender Address

RestrictIPAddress=list of IP addresses

EnableCreditBalance=Yes/No

CreditsToAdd=####

MessageLimitDefault=Yes/No

MessageLimitPerDay=####

MessageLimitPerMonth=####

RecipientAddresses=list of recipient phone numbers that should be routed to this account

WebOptions=All/Advanced/TextOnly/Text/SMSMMS/SMSWAPMM/SMSMMSWAPMM

AdminEnabled=Yes/No (version 2011.10.18 and later)

ReceiveEnabled=Yes/No (version 2011.10.18 and later)

As an example, to add credits to an existing account, issue the following URL request:

http://server:port/provision?Type=SMS&AdminAction=Modify&Name=accountname&CreditsToAdd=100

Assuming that the user is authorized to issue a provisioning command (valid username/password, and supported IP address for originating the request), the server will return a normal HTTP response code of 200 with a MIME content type of “text/plain”. The response will start with “OK” if the request was successful, or “ERROR” if the request failed. If a”CreditsToAdd” parameter was specified, or ”AdminAction=CreditCheck”, the HTTP response will include the text ”Credits=####”, where “####” is the current balance for the account.

If a parameter of ”Type=MMS“ is specified, the following parameters are supported:

AdminAction=Add, Modify, Delete, or CreditCheck

PhoneNumber=phonenumber

Name=Alias

Password=password

Fullname=Full Name

MessageLimitDefault=Yes/No

MessageLimitPerDay=####

MessageLimitPerMonth=####

This bug only effects configurations where NowSMS is being used as an SMPP server.  In other words, an SMPP client is being used to submit messages to NowSMS, and messages are being segmented by the SMPP client before they are submitted to NowSMS.  (If the client uses message_payload submission and allows NowSMS to segment messages, the problem does not occur.)

This bug could cause up 1 to 3 extra @ characters to be appended to message text for long messages that require 3 or more segmented messages.  Specifically effected were messages where the final segment contained less than 4 characters of text, where extra @ characters might be added to cause the segment to have at least four characters.  For example, messages with between 207 and 209 characters inclusive would be padded to 210 characters with extra @ characters at the end.  Messages with between 460 and 462 characters inclusive were similarly effected, and padded to 463 characters in length.

(Effected messages had character lengths between (x * 153) + 1 and (x * 153) + 3 inclusive, where x is larger than 2.)

An updated release of NowSMS, which corrects this problem, is available at http://www.nowsms.com/download/nowsms20120209.zip.

An updated release of NowSMS Lite which includes this fix is available at http://www.nowsms.com/download/lite20120209.zip.

Please note that there are numerous other issues that can cause @ characters to appear unexpectedly in SMS messages, which are not specifically related to this bug.  This bug only effects messages of the specified lengths in the listed versions of NowSMS.

Other unexpected problems related to the  @ character can occur because in the GSM character set, the @ character is represented by a NULL (value of 0).

If  you experience a problem where your text messages are truncated at an @ character, or @ characters are missing from text messages, this is indicative that you are using a different character set than the SMSC.  If you experience this problem with an SMPP connection, we recommend changing the “SMSC Character Setting” for the SMPP connection to use iso-8859-1, as this problem suggests that the SMPP provider is expected use of the iso-8859-1 character set.  By default, NowSMS uses the GSM character set for SMPP connections.

If you are experiencing problems sending particular characters via SMS, please post a query in our discussion forums at http://www.nowsms.com/messages.

The problem occurs because the MMS client cannot process an MMS notification message where the MMS Content URL contains a URL escaped parameter.  When the MMS client encounters a URL escaped parameter in a URL, it re-encodes the URL with another level of URL escaping.  As an example, if the MMS client receives an MMS notification which includes a URL with a parameter ?id=%2b, the MMS client converts this to ?id=%252b.  This errant conversion causes the MMSC to be unable to determine the message that the client is asking to retrieve.

As a work-around for this issue, the following configuration setting can be applied in the [MMSC] section of the MMSC.INI file:

CompactMMSURL=Yes

This setting changes the format of the MMS content URL so that it will not include any URL escaped parameters, and will avoid the bug in the Nokia N9 MMS client.

The original intended effect of this setting was to reduce the length of the MMS Content URL by 14 bytes.  This setting should have no other effect on operation.

An updated release of the NowSMS MMSC is also available at http://www.nowsms.com/download/nowsms20120209.zip, which implements a work-around for this problem without requiring any special configuration settings.

For a VB.NET version of this example, please see the related article Send MMS from VB.NET.

MMS examples for other environments (PHP, Java, command line) can be found at http://www.nowsms.com/sending-mms-messages-with-nowsms.

As discussed in Sending MMS Messages with NowSMS, one of the easiest ways to interface with NowSMS for sending MMS messages is to use what we refer to as the Proprietary URL Submission interface.  This interface is the one used for sending messages via the forms in the built-in NowSMS web interface.  Sending an MMS message via this interface is a matter of using an HTTP POST to submit MMS content in the form using the MIME type “multipart/form-data”.  This technique is often referred to as “HTTP File Upload” and is associated with web pages that have a “Browse” button that allows files to be uploaded.

There’s a great C#.NET HTTP File Upload library at: http://aspnetupload.com/Upload-File-POST-HttpWebRequest-WebClient-RFC-1867.aspx

A direct link to download the library is here (only the UploadHelper component is needed): http://aspnetupload.com/AspNetUploadSamples.zip

In the event that this link does not work in the future, we have archived a copy of the library at the following link:

AspNetUploadSamples.zip AspNetUploadSamples.zip(388.7 k)

The following code example uses code from that library to send an MMS message:

(Note: This example can be downloaded at http://www.nowsms.com/download/sendmms.c#.txt.)

// Set the following variables as appropriate for your system. 

// URL that points to NowSMS web interface 
Uri url = new Uri("http://127.0.0.1:8800/"); 

// Valid username/password for account defined in NowSMS under "SMS Users". 
String username = "testuser"; 
String password = "testpass"; 

// Images & Files to be included in the message. 
// First parameter is filename and path. 
// Second parameter must be MMSFILE 
// Third parameter should be MIME type 

UploadFile[] files = new UploadFile[] 
{ 
new UploadFile("f:\\temp\\image1.png", "MMSFILE", "image/png"), 
new UploadFile("f:\\temp\\image2.jpg", "MMSFILE", "image/jpeg"), 
}; 

// Create additional form parameters for sending MMS 
NameValueCollection form = new NameValueCollection(); 

// "PhoneNumber" variable contains recipient phone number 
form["PhoneNumber"] = "9999999999"; 
// "MMSFROM" variable contains sender phone number or address
//  (Note: Ignored when sending via modem) 
form["MMSFROM"] = "9999999999"; 
// "MMSSUBJECT" variable contains subject line for message 
form["MMSSUBJECT"] = "test subject"; 
// "MMSTEXT" variable contains test to appear in message (optional) 
form["MMSTEXT"] = "This is a test message"; 

// Send the request to NowSMS, creating an HttpWebRequest and 
// then use HttpUploadHelper to send files in multipart/form-data format 
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url); 

var credCache = new CredentialCache(); 
credCache.Add(url, "Basic", new NetworkCredential(username, password)); 
req.Credentials = credCache; 

HttpWebResponse resp = HttpUploadHelper.Upload(req, files, form); 

// Read the HTTP response and echo to console 
using (Stream s = resp.GetResponseStream()) 
using (StreamReader sr = new StreamReader(s)) 
{ 
string response = sr.ReadToEnd(); 
System.Console.WriteLine(response); 
}

Additional MMS options can be included using the form["variablename"] = “value” syntax shown in the above example. The other options/variables are described in more detail in http://www.nowsms.com/sending-mms-messages-with-nowsms.

For a C# .NET version of this example, please see the related article Send MMS from C# .NET.

MMS examples for other environments (PHP, Java, command line) can be found at http://www.nowsms.com/sending-mms-messages-with-nowsms.

As discussed in Sending MMS Messages with NowSMS, one of the easiest ways to interface with NowSMS for sending MMS messages is to use what we refer to as the Proprietary URL Submission interface.  This interface is the one used for sending messages via the forms in the built-in NowSMS web interface.  Sending an MMS message via this interface is a matter of using an HTTP POST to submit MMS content in the form using the MIME type “multipart/form-data”.  This technique is often referred to as “HTTP File Upload” and is associated with web pages that have a “Browse” button that allows files to be uploaded.

There’s a great C#.NET HTTP File Upload library at: http://aspnetupload.com/Upload-File-POST-HttpWebRequest-WebClient-RFC-1867.aspx

A direct link to download the library is here (only the UploadHelper component is needed): http://aspnetupload.com/AspNetUploadSamples.zip

In the event that this link does not work in the future, we have archived a copy of the library at the following link:

AspNetUploadSamples.zip AspNetUploadSamples.zip(388.7 k)

The following VB.NET code example uses code from that library to send an MMS message:

(Note: This example can be downloaded at http://www.nowsms.com/download/sendmms.vb.txt.)

Imports System.Text
Imports System.IO
Imports System.Net
Imports System.Web
Imports System.Web.Services
Imports ClassLibrary1
Imports ClassLibrary1.Krystalware
Imports ClassLibrary1.Krystalware.UploadHelper
Imports ClassLibrary1.Krystalware.UploadHelper.HttpUploadHelper
Imports ClassLibrary1.Krystalware.UploadHelper.MimePart
Imports ClassLibrary1.Krystalware.UploadHelper.StreamMimePart
Imports ClassLibrary1.Krystalware.UploadHelper.StringMimePart
Imports ClassLibrary1.Krystalware.UploadHelper.UploadFile
Imports System.Collections.Specialized

Public Class Form1
    Public Sub SendMMS()
        ' Set the following variables as appropriate for your system.
        ' URL that points to NowSMS web interface
        Dim url As New Uri(" http://127.0.0.1:8800/ ")

        ' Valid username/password for account defined in NowSMS under "SMS Users".
        Dim username As [String] = "testuser"
        Dim password As [String] = "testpass"

        ' Images & Files to be included in the message.
        ' First parameter is filename and path.
        ' Second parameter must be MMSFILE
        ' Third parameter should be MIME type 

        Dim files As UploadFile() = New UploadFile() {
         New UploadFile("c:\mms\tts.mp3", "MMSFILE", "audio/mpeg"),
         New UploadFile("c:\mms\image.png", "MMSFILE", "image/png")}

        ' Create additional form parameters for sending MMS
        Dim form As New NameValueCollection()

        ' "PhoneNumber" variable contains recipient phone number
        form("PhoneNumber") = "09059999999"
        ' "MMSFROM" variable contains sender phone number or address
        '  (Note: Ignored when sending via modem)
        form("MMSFROM") = "09058888888"
        ' "MMSSUBJECT" variable contains subject line for message
        form("MMSSUBJECT") = "test subject"
        ' "MMSTEXT" variable contains test to appear in message (optional)
        form("MMSTEXT") = "this is a test message"

        ' Send the request to NowSMS, creating an HttpWebRequest and
        ' then use HttpUploadHelper to send files in multipart/form-data format
        Dim req As HttpWebRequest = DirectCast(WebRequest.Create(url), HttpWebRequest)

        Dim credCache = New CredentialCache()
        credCache.Add(url, "Basic", New NetworkCredential(username, password))
        req.Credentials = credCache

        Dim resp As HttpWebResponse = HttpUploadHelper.Upload(req, files, form)

        ' Read the HTTP response and echo to console
        Using s As Stream = resp.GetResponseStream()
            Using sr As New StreamReader(s)
                Dim response As String = sr.ReadToEnd()
                MsgBox(response)
                System.Console.WriteLine(response)
            End Using
        End Using
    End Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        SendMMS()
    End Sub
End Class

Additional MMS options can be included using the form(“variablename”) = “value” syntax shown in the above example. The other options/variables are described in more detail in http://www.nowsms.com/sending-mms-messages-with-nowsms.

In addition to the HHE issues discussed in that article, we frequently receive questions about using HTTP Cookie headers for identifying the MSISDN.

These questions are usually asked for the following reasons:

• Customers migrating from or augmenting an Ericsson MIEP may have applications that expect to receive the MSISDN via HTTP Cookie headers.
• The Opera Mini browser has a tendency to remove the X-MSISDN header that NowWAP would usually generate.

For these reasons, recent versions of NowWAP (2011 and later), support a built-in option that can be used to automatically add an HTTP Cookie header for the MSISDN.

To enable this option, edit WAPGW.INI, and under the [WAPGW] header, add MsisdnCookieHeaders=Yes

When this option is set, NowWAP will generate an HTTP Cookie header for the MSISDN, in addition to the standard X-MSISDN header, when communicating with any content domains that are enabled for Basic HHE.

For compatibility purposes, NowWAP generates an HTTP Cookie Header using a format similar to those generated by the Ericsson MIEP:

Cookie: User-Identity-Forward-MSISDN=1234567890

If IMSI information is available via RADIUS, the IMSI will also be included in a User-Identity-Forward-IMSI cookie.

This interface is described in more detail in the following article:

http://www.nowsms.com/xml-status-query-for-smsc-connection-status-and-statistics

An XML Schema Definition can be found in the following article:

http://www.nowsms.com/xml-status-query-for-smsc-connection-status-and-statistics-2

As we frequently receive questions asking how this status information can be accessed via a PHP script, this article will provide some simple examples.

The PHP SimpleXML functions are the easiest way to access and process this information.

In a discussion board posting (http://www.nowsms.com/discus/messages/1/60149.html), we previously provided a simple example of a PHP script that queries the number of messages waiting in the NowSMS outbound SMS message queue.

The first step to access the data is to load the status URL into a SimpleXML object:

<?php

$xmldata = file_get_contents
             ("http://127.0.0.1:8800/admin/xmlstatus?user=adminuser&password=adminpass");

$xml = simplexml_load_string($xmldata);

?>

Substitute in your appropriate IP address and port, and the appropriate “adminuser” and “adminpass” values for your NowSMS installation.

To report the number of messages in the outbound SMS message queue, simply access the following variable:

$xml->SMSOUTQ

To report the number of messages sent out today, or in the last 7 or last 30 days, use the following variables:

$xml->SMSSent->MessagesToday
$xml->SMSSent->MessagesLast7Days
$xml->SMSSent->MessagesLast30Days

To report the number of active SMPP client connections, use the following variable:

$xml->SMPPClientList->ActiveConnectionCount

Refer to the XML examples and schema referenced in the earlier links to see other status information that is available via this XML-based interface.

As an additional example, here is code that queries SMSC connection status and reports any connections that are experiencing connectivity problems:

<?php

$xmldata = file_get_contents
            ("https://127.0.0.1:8801/admin/xmlstatus?user=adminuser&password=adminpass");

$xml = simplexml_load_string($xmldata);

$allConnectionsOK = true;

foreach ($xml->SMSCStatus as $smscStatus) {

   if (strcasecmp ($smscStatus->Status, "OK")) {

      $allConnectionsOK = false;

      echo "Connection Error: " . $smscStatus->Name . " -- " . $smscStatus->StatusDetail . "\n";

   }

}

if ($allConnectionsOK) {

   echo "OK\n";

}

?>

For more information on using the SimpleXML functions, please refer to the PHP documentation at:   http://us.php.net/manual/en/book.simplexml.php

For more information on the NowSMS Status Query XML interface, please refer to the following articles:

• http://www.nowsms.com/xml-status-query-for-smsc-connection-status-and-statistics
• http://www.nowsms.com/xml-status-query-for-smsc-connection-status-and-statistics-2

The MMSC user database had become corrupt, preventing new users from being able to be automatically provisioned.  While it is not known why this corruption occurred, the most common potential cause is an abnormal system shutdown, such as power failure.

Future versions of the MMSC will include start-up logic to detect and repair corrupt MMSC user databases automatically.  However, the following instructions for manual repair may be helpful if someone else encounters this problem.

Copy the MMSCUSERS.DB file (normally located in \ProgramData\NowSMS) to another location. Also copy SQLITE3.EXE from the NowSMS program directory.

From a command line prompt, issue the following command:

sqlite3 mmscusers.db

This command  should bring you to an sqlite> prompt.

Issue the following command:

select name from sqlite_master where type='table';

The system should respond back with:

Users
sqlite>

Issue the following command:

select count (*) from users;

The system should report how many users are in the database.

Issue the following command:

pragma integrity_check;

If the database is corrupt, this command should return an error.  If there is no corruption problem, this command will return OK.

Use the .quit command to exit the sqlite3 utility.

To attempt to recover the database, issue the following command:

sqlite3 mmscusers.db .dump > mmscusers.txt

mmscusers.txt will be a text file of SQL commands containing a database dump.

Inspect this text file to confirm that it has close to the number of users expected. If it does not, please contact NowSMS support for further analysis.

To create a new repaired database, issue the following command:

sqlite3 mmscusersnew.db < mmscusers.txt

The repaired database will be named mmscusersnew.db. Rename to mmscusers.db and replace the original database in the NowSMS data directory. It is necessary to stop the NowSMS services in order to do this.

For example, an end user in the UK might want to send an SMS message to 0777777777 using the local number format, but the upstream SMSC connection requires a country code to be specified, such as +44777777777.

An end user in the US might sometimes prefix a number with 1, and other times not.

Starting with the 2011.07.05 release of NowSMS (see http://www.nowsms.com/category/updates), there are configuration settings that can be used to perform these types of phone number prefix conversions on a per SMSC basis.

* SMS Gateway:  Add support for prefix number conversion when submitting SMS messages to an SMSC connection in order to deal with situations where a particular provider requires national or international number format.  In the SMSC specific section of SMSGW.INI (e.g., [Modem - modem driver name] or [SMPP - server:port]) the following settings are now supported to apply number prefix conversions for inbound or outbound messages:  OutRecipPrefixConvert, OutSenderPrefixConvert, InRecipPrefixConvert, InSenderPrefixConvert.  These settings apply to sender (source) and recipient (destination) addresses, as denoted in the settings name.  Prefix conversions can be a comma delimited list, such as 00:+,0:+44   In this case, 0044777777777 is converted to +44777777777, and 0777777777 would be converted to +44777777777.  For outbound messages, the conversion occurs before the message is submitted via this SMSC connection.  For inbound messages, it is applied as the message is received from the SMSC connection.

In most cases, you would be applying conversions for the recipient phone number.

For example, a conversion that assumes UK local numbers being converted to international format would look like this:

[SMPP - server:port]
OutRecipPrefixConvert=00:+,0:+44

With the above setting, 0044777777777 would be converted to +44777777777, and 0777777777 would be converted to +44777777777.

If the connection is an SMPP connection, the “+” is not actually included in the recipient address, but instead NowSMS uses this as a signal to indicate that the recipient TON (dest_addr_ton) value should be set to 1 to indicate an international number.

A similar conversion for USA local numbers would look like this:

[SMPP - server:port]
OutRecipPrefixConvert=011:+,1:+1,2:+12,3:+13,4:+14,5:+15,6:+16,7:+17,8:+18,9:+19

With the above setting, 01144777777777 (011 being an old style prefix for an international phone number) would be converted to +44777777777.

15555551212 would be converted to +15555551212.

5555551212 would be converted to +15555551212.

It may also be necessary to specify more than one SMPP connection to the same SMSC in order to process messages for more than one short code.  In this latter case, you may need to specify different credentials for each SMPP connection.  In this case, simply add a second (or third, or fourth…) SMPP connection, specifying the same server address.  When NowSMS adds the connection to the SMSC list, it will automatically append “#2″ (or #3, or “#4″) to the SMSC address in order to maintain separate settings for each connection.

However, if you are connecting to the same SMSC multiple times using the same account credentials, it can be inconvenient to define the same connection multiple times.  For this reason, NowSMS 2011.07.05 and later releases (see http://www.nowsms.com/category/updates) provide a configuration interface to define the number of transmitter, receiver and/or transceiver connections to be allocated for a single SMPP connection, without requiring multiple duplicate connections to be defined.

To configure these settings, edit the “Properties” of an SMPP connection, and in the “Advanced Settings” menu, the following settings are available:

If “Send and Receive Messages over the same Connection (SMPP Transceiver)” is enabled, specify the number of concurrent SMPP Transceiver sessions that NowSMS should establish.  (Transceiver sessions support both sending and receiving messages over the same connection/session.)

If this transceiver mode is not enabled, the number of Transmitter and Reciever Sessions can be configured independently.

These settings can also be manually configured by editing SMSGW.INI.

In the [SMPP - server:port] section of SMSGW.INI, the following settings are used:

TransmitterCount=##
ReceiverCount=##

TransmitterCount=## defines the number of transmitter connections to be established. If transceiver mode is configured, TransmitterCount specifies the number of transceiver connections to be established. If transceiver mode is not configured, ReceiverCount specifies the number of receiver connections to be established.

This document details the update release history since the previous official release, version 2010.11.04.  Release history for the changes prior to the current official release can be found at  http://www.nowsms.com/category/updates.

Customers running any earlier 2011 interim release of NowSMS are strongly encouraged to update to this release due to a number of problems that exist in earlier 2011 interim releases. (If upgrading is not possible, as a  precaution delete the file NLS.INI if it exists in the Program Files\NowSMS directory, which will disable SMS shift table support that was introduced earlier this year.  Note that this recommendation applies only to NowSMS 2011 releases prior to 2011.07.05.  Do not delete this file if running NowSMS 2011.07.05 or later.)

Highlights of this update:

1.) Configuration changes no longer require a NowSMS service restart.  The NowSMS service will activate configuration changes without requiring a full service restart.

2.) Updated web interface templates (we know … the old ones were perfectly functional, but yes, they were a throwback to web 1.0, or possibly web 0.5).

3.) Increased administrative capabilities from the web browser.  In addition to statistics and log files, it is possible to view alerts, recent activity, inbound and outbound messages.  It is also possible to add and update user accounts.

4.) Easier configuration of logical SMSC Route Names (as compared to server addresses in earlier releases).

5.) SMS Shift Table Support (of interest primarily for those working with Turkish and Portuguese languages, as well as for handset developers/testers working to add support for SMS shift tables in languages of the Indian subcontinent).  For more information, see http://www.nowsms.com/tag/sms-shift-table.

6.) SMPP connections can define multiple transmitter and/or receiver sessions.

7.) SMPP relay improvements – Support for absolute format validity_period settings, support for additional values in message_state TLV parameters.  Also accounting callbacks can now have the capability to modify TLV parameters, as well as source and destination addresses.

8.) MM4 – Addressed an issue with missing originator/From fields for messages from a particular operator.

9.) E-mail alert improvements (can use SMTP authentication and SSL/TLS to send out via an account).

10.) Numerous accounting callback enhancements (more detailed information can be found in the release notes).

11.) Local PHP script support.  NowSMS can now host PHP scripts directly, so that you do not need to configure an external web server for hosting 2-way commands or accounting callbacks.  For more information, see http://www.nowsms.com/now-sms-native-php-scripts.

12.) SMPP – Improved handling of throttling errors especially as an effort to keep multiple parts of a segmented message from being separated.

There are numerous other minor updates that are detailed in the release history information below.  The release history information provides additional information on configuration settings that have been added to address unusual configuration requirements.

2011-07-05:

• SMS Gateway: SMS accounting callbacks can now be used to route messages to an external SMSC account, or to a local user account. When the “SMSSend” accounting callback is issued, it is possible for the callback to return SMSCRoute=routename in the HTTP response to specify an external route via which the message should be routed, or SMSCRoute=localuser:username to route the message to a local user account.
• SMPP: message_state TLV parameter is now set according to the text of the delivery receipt. Previously a value of 5 (undeliverable) was used for all undeliverable status conditions. Most notable, a value of 3 is now correctly used for messages that were marked expired.
• Web Interface: Update “Send Text Message” HTML form to address issue where Chrome and Firefox count a line break as one character, but when posting the message, post two characters instead. (Counter now counts two characters for a line break, assuming the browser will post two characters.) IE counts two characters and posts two characters.
• SMS Gateway: Add support for prefix number conversion when submitting SMS messages to an SMSC connection in order to deal with situations where a particular provider requires national or international number format. In the SMSC specific section of SMSGW.INI (e.g., [Modem - modem driver name] or [SMPP - server:port]) the following settings are now supported to apply number prefix conversions for inbound or outbound messages: OutRecipPrefixConvert, OutSenderPrefixConvert, InRecipPrefixConvert, InSenderPrefixConvert. These settings apply to sender (source) and recipient (destination) addresses, as denoted in the settings name. Prefix conversions can be a comma delimited list, such as 00:+,0:+44 In this case, 0044777777777 is converted to +44777777777, and 0777777777 would be converted to +44777777777. For outbound messages, the conversion occurs before the message is submitted via this SMSC connection. For inbound messages, it is applied as the message is received from the SMSC connection.
• 2-way SMS: Add support for @@SMSCROUTEID@@ replaceable parameter to contain the unique route name identifier (e.g., “Modem – Driver Name” or “SMPP – host:port”). If the same route name is assigned to multiple connections, the route name is used for @@SMSCROUTE@@. @@SMSCROUTEID@@ allows distinction of which connection the message was received form.
• SMS Gateway: Add SMSGW.INI [SMSGW] setting, UserOutboundQueueLimitInterval=## to specify the delay interval between user queue size scans when the UserOutboundQueueLimit=## setting is used.
• SMS Gateway: Fix for exception errors related to improper decoding of some messages that make use of a single shift table.

2011-06-20:

• SMPP: Absolute format validity_period setting is now supported from SMPP clients. HTTP clients can also use the “&Validity=” parameter to submit a validity_period setting in SMPP format. (SMPP format validity period will only be forwarded to upstream SMPP connections.
• MMSC: MmsMessageSizeLimit=#### (value in KB) setting in MMSC.INI now also applies to MM7 and MM4 submissions.
• MMSC: Handle situation where the HTTP POST from an MM7 client includes a host name in the POST URL. Normally the POST URL in the HTTP request only includes a host name in the URL if the submission is being routed via an HTTP Proxy. MMSC already handles this case for MM1 submissions, but not for MM7 submissions until this release. (According to HTTP 1.1 specification, servers must accept this format, but client should not generate this format unless posting via an HTTP proxy.)

2011-06-15:

• 2-way SMS: Additional fix for restarts associated with a bug introduced in 2011.05.23 version for 2-way SMS messages that include SMPPOptions parameters.

2011-06-09:

• SMS Gateway: Fix for a resource leak that can be caused by inbound SSL connnections (HTTP or SMPP) that do not complete the SSL handshake.

2011-06-08:

• 2-way SMS: Fix for restarts associated with a bug introduced in 2011.05.23 version for 2-way SMS messages that include SMPPOptions parameters.

2011-06-06:

• MM4: Fix for a problem where messages received from a particular operator had a missing originator/From field. This was caused by unexpected horizontal tab characters being included in the SMTP “From:” header. According to the SMTP specification, these horizontal tab characters are legal, and NowSMS needs to ignore them.

2011-06-03:

• SMS Gateway Startup: Move most database integrity checks to a background thread so as to not delay startup.
• 2-way SMS commands with mailto: links: Support routing e-mail non-delivery messages back to sender if message undeliverable.

2011-06-02:

• SMS Gateway: Fix for 2011-05-23 interface reporting errors with the SMPP server if an SSL port number for SMPP is not defined.
• SMS Gateway: Route names are now supported in the configuration interface to make it easier to work with SMSC connections. “SMSOUT” and “SMSIN” accounting callbacks now include “&SMSCRouteName=” parameter.
• SMS Gateway: Fix for problem where server would not take extra time to shutdown if HTTP SSL connections are supported.

2011-05-23:

• SMS Gateway Web interface:  Update NowSMS web user interface templates.
• SMS Gateway:  Web Administration Access is now associated as an attribute to an “SMS Users” account, instead of being a separate login identity.
• SMS Gateway:  E-Mail alerts can now specify to be sent via a mail server that requires with SMTP Authentication & SSL/TLS.
• SMPP: Configuration program supports defining the number of simultaneous transmitter and/or receiver sessions to be associated with an SMPP SMSC connection.
• HTTP SMSC: Configuration program supports defining the number of simultaneous HTTP transmitter sessions to be associated with an HTTP SMSC connection.
• SMPP: Seldom used configuration parameters for specifying the local TCP port that the SMPP client should bind to have been removed from the configuration program interface. These parameters continue to be supported by manual configuration file entries under the [SMPP - server:port] section header of SMSGW.INI: SenderPort=#### specifies the local TCP port to be used for the transmitter or transceiver session, and ReceiverPort=#### specifies the local TCP port to be used for the receiver session.
• SMPP:  Fix for [SMPP] / DeliveryReceiptFlag=Yes not working properly. (Only worked properly if set as [SMPP] / DeliveryReceiptFlag=1)
• SMS Gateway:  Fix for SMS service restarts/exception errors that could be triggered by updating the SMSGW.INI file. (Problem was introduced in 2011.03.15 update.)
• SMS Gateway: Fix for service restarts that could occur when using the web administrative interface.
• SMS Gateway & MMSC:  Various configuration restarts no longer require a service restart. (SMSC connections can be added/deleted/modified without requiring a restart. Configuration changes will take effect within within approximately 60 seconds.)
• Accounting callbacks now have the ability to change sender/recipient values (useful for source address translation when routing messages), and the ability to modify service type, validity and defined SMPP TLV parameters. This capability is enabled in the “SMSSend” and “SMSIN” accounting callbacks when SMSAccountingAllowChanges=Yes is defined in the [SMSGW] section of SMSGW.INI. When this setting is present, NowSMS will parse the HTTP response for “SMSSend” and “SMSIN” accounting callbacks looking for “To=”, “Sender=”, “ServiceType=”, “Validity=” and “SMPPOption_xxxx=” settings. If any of these text strings are present, the value that follows will be used to replace the existing value. (In the case of SMPPOption_xxxx=, a blank value will completely remove the parameter.) It is recommended that the HTTP response terminate the value with a new line to act as an end of value string delimiter.
• SMPP: TLV parameters defined in GSM Assocation IR.75 are automatically supported by default using the HexString encoding: SMPPOption_source_subaddress (0×202) and SMPPOption_dest_subaddress (0×203). For more information, refer to http://www.nowsms.com/smpp-tlv-parameters-for-advanced-message-routing
• Retrieving SMS messages via POP3: Fix for carriage return/line feed in an SMS message appearing as \r\n when converted to e-mail format. Also add sender phone number to subject line of message.
• SMPP Client: Previously NowSMS tracked upstream SMPP message IDs only if the client asked for a delivery report (or non-delivery report). However, many SMPP servers always return delivery reports, which can cause confusion, because if NowSMS did not track the upstream message ID, it will not know how to route it or resolve the message ID. NowSMS now always tracks the upstream SMPP message ID, unless TrackSMPPReceiptsAlways=No is set under the [SMSGW] header of SMSGW.INI.
• MMSC: Include “MMSStatus=” in “MMSDeliveryReport” callbacks. Status values are extracted from the MMS specifications. Possible values include “Retrieved” (success), “Expired”, “Rejected”, “Deferred”, Unrecognised”, “Indeterminated”, “Forwarded”, “Unreachable” and “Unknown”.
• MMS Proprietary URL Submission: Include “MMSMessageID=” parameter in accounting callback for MMS message submissions via this interface.
• MMSC: Reduce DNS query timeouts that can backlog the processing of MM4 acknowledgments, especially when the “MM4 Ack Route” has not been set for a connection.
• MMSC: Fix for bug receiving MMS messages via MM4 which included filenames that have a “?” character in the filename.
• E-Mail to SMS: When routing e-mail to SMS, a new configuration option supports tracking the e-mail sender address, so that an SMS reply can be routed back to the original e-mail sender. Note that when this tracking option is enabled, if multiple e-mail senders send to the same SMS phone recipient, NowSMS cannot distinguish which e-mail address should receive the reply, and the reply will be directed to the most recent e-mail sender. To enable this tracking, add SMSEMailTrackSender=Yes to the [MMSC] section of MMSC.INI. If it is possible for NowSMS to send/receive SMS using multiple SMS numbers, NowSMS can use the multiple SMS numbers to improve tracking if multiple e-mail addresses send to the same SMS recipient. To define the SMS sender numbers to be used for e-mail to SMS, add SMSEMailSender= to the [MMSC] section of MMSC.INI. SMSEMailSender supports a comma delimited list of sender numbers, and also supports ranges of sender numbers such as 800001-800100 to allocate a sequential range of numbers.
• SMS Gateway: Additional subdirectories created to prevent situations where a large SMS-IN queue makes the system unstable.
• SMS Gateway: NowSMS can now host PHP scripts locally (accounting callbacks, 2-way commands) without requiring an external web server. Further information and details are avaialble at http://www.nowsms.com/now-sms-native-php-scripts

2011-04-19:

• SMS Gateway: Add configuration parameter to allow customisation of the maximum message length for automatic message segmentation to allow for smaller segments that may be necessary in some environments. These settings can be configured under the [SMSGW] section header of SMSGW.INI, using the following parameters: MaxSMSSegmentLengthText=160 and MaxSMSSegmentLengthBinary=140
• 2-Way SMS: Previously NowSMS would only retry a 2-way SMS command if the connection to the web server failed or a timeout error occurred. It would not retry the command if the web server returned an HTTP error (such as 500 Internal Error), and would simply rename the message file to have a .BAD extension. This version changes the behaviour to perform retries with progressive delays, similar to the processing of outbound SMS messages. By default, NowSMS uses the same retry parameters as described at http://www.nowsms.com/sms-retry-error-handling-with-ucpemi-and-cimd. To define retry parameters specific to 2-way SMS processing, place them under a [2Way] section header in SMSGW.INI, instead of under the [SMSGW] section. If a server hosting a 2-way command is down and is not accepting connections or not returning a valid HTTP response, NowSMS continues to retry the 2-way command indefinitely, but it does introduce a progressive delay for these retries.
• MMSC: Performance optimisation for configuration front end open and displaying statistics, particularly on a multiple server installation, where if the configuration program were open simultaneously on multiple servers, it would become sluggish or unresponsive until other copies were closed.
• 2-Way MMS: Add configuration option to simplify processing received MMS messages so that they can be posted to a PHP script via HTTP. Previously, it was necessary to create an “MMSC Routing” definition to point to a PHP script. That mechanism is still supported, but it is also possible to now define a 2-way MMS POST URL on the “2-way” page of the configuration. The URL defined on this page will process any received MMS messages that get posted to the MMS-IN directory. The format of the POST uses the PHP format described at http://www.nowsms.com/doc/2-way-mms-support/receiving-mms-messages-with-a-php-script

2011-04-11:

• Configuration Program: Update font selection for configuration program to address issues where some installations were seeing text that was too large to display in the window.
• SMS Gateway: Fix for problem that could occur if an automated program submitting messages via HTTP uses multiple user accounts over a single HTTP connection. If some user accounts have “forced sender address” configured, and some do not, the “forced sender address” from a previously accessed account would be applied to submissions from an account with no “forced sender address” setting. Note that this could only occur if a program was submitting over a single HTTP connection using multiple user accounts for different message submissions.

2011-03-21:

• SMS Gateway: Fix for web interface not working properly with Firefox. (Problem introduced with late 2010 update to enable keep alive sockets.)

2011-03-18:

• MMSC: Fix for problem in a multiple server installation (SHAREDVOLUME.INI) where only one front-end would actively listen for connections for MMS messages converted to SMS. (Fix was attempted in 2011-03-15 version, but did not completely fix the problem.)

2011-03-15:

• SMS Gateway: Add configuration setting to limit individual user accounts from flooding the outbound message queue. This setting enforces a maximum number of queued messages that any individual user account can have pending in the outbound message queue. If a user attempts to submit additional messages when over the limit, a throttling error will be returned. To enable this throttling, the setting UserOutboundQueueLimit=##### must be added to the [SMSGW] section of SMSGW.INI. The ##### value sets a default maximum outbound message queue size to be applied to all user accounts. (A special value of 0 means no limit, but enables non-default settings to be applied to individual user accounts.) To override the default setting for individual user accounts, create an [UserOutboundQueueLimit] section, and add username=##### to this section to enable a limit for a specific user account. (A value of 0 will disable limits for that user account.) Note that queue size monitoring experiences a 30 to 60 second delay, so it is possible that users may slightly exceed configured limits. Also note that for SMPP accounts, care is taken to ensure that a throttling error does not occur in the middle of a multipart message transmission.
• SMS Gateway: Improved handling of “User Queue Size Threshold” to prevent problems where SMPP user accounts could be allocated multiple queue directories, giving extra priority to that account.
• SMS Gateway: The SMSGW.INI SMSCSendLimit=x/y setting, which can limit the speed at which messages are sent via a specific SMSC connection, was not functioning accurately at higher speeds. The setting has been reworked to support throttling at higher speeds.
• SMS Gateway: Fix for changes to the [Inbound SMS Routing] table (used for routing received messages to local user accounts based upon recipient address matching) not automatically being reloaded by the server without a restart.
• 2-Way SMS Command Processor: Fix for a problem where a message with invalid UDH could be posted repeatedly to a 2-way command. The problem could occur if the user data header indicated a multipart message where the current part number was larger than the number of indicated message parts.

2011-02-16:

• SMS Gateway: Add configuration option to duplicate SMPP receipts being routed to a local SMPP user account, so that they are also routed to 2-way command processing. This setting would be used when an installation needs to process all delivery receipts via a 2-way command. To enable this option, edit SMSGW.INI, and under the [SMSGW] header, add DuplicateUserReceiptsFor2Way=Yes.

2011-01-14:

• SMPP Server: Fix for a change first introduced in 2010-05-20 version which could cause extra null messages to be delivered to connected SMPP clients. This problem could only potentially occur if a client had multiple receive (or transceive) connections open to the NowSMS SMPP server.
• MMSC: Change MM7 transaction ID format to not include @ character, due to suspcion that this was causing a problem for a particular provider.

2010-12-21:

• MM7: When AllowAlphaRecip=Yes is enabled, use <Number> instead of <ShortCode> for the recipient address type, even if it is not a number.
• Configuration program opens LOG files using the default program for the .LOG extension instead of always using Notepad.

2010-12-14:

• MMS via GPRS Modem: Fix for problem introduced in 2010.11.04 version where MMS messages would not be retrieved from some operator MMSCs, particularly T-Mobile USA.

2010-12-07:

• Web Interface: Fix for problem sending pre-compiled MMS messages via the “Send MMS Message” web interface that could cause these messages to become corrupted.
• SMS Gateway/SMPP Client: When a throttling error occurs, additional logic requeues the message that triggered the error so that several retries will be attempted without requiring a pass through the entire message queue before the message is retried. This is necessary for proper handling of multipart segmented messages, so that if one part of the message encounters a throttling error, it can still be transmitted within the same window as other parts of the message when the outbound message queue is very full.
• MM7: Don’t add extra CRLF before closing MIME boundary as this might be confusing some Java libraries.

2010-11-26:

• MMSC: Fix for problem where the message ID in a delivery receipt was not formatted correctly (“/” characters changed to “.”) for delivery receipts that arrived via an MM4 connection. This prevented sending clients from being able to correctly resolve delivery receipts.
• SMS Gateway: Fix for web admin interface only sending the first 16KB when attempting to remotely download log files.

This post provides some example PHP functions that can be used to simplify this process.  Now that NowSMS can support PHP scripts natively without a separate web server, it is even easier to prototype SMS applications with NowSMS.

In this example, we’ll use these example PHP functions to allow users to send an SMS message to the NowSMS server to add or remove themselves from a distribution list, and allow any member of a distribution list to send a message that is broadcast to all distribution list members.

This is intended as an example only, and a starting point for adding further logic.

nowsmsdlist.php is a PHP include file that contains functions for working with NowSMS distribution lists.  This file can be downloaded at the following link:  http://www.nowsms.com/examples/nowsmsdlist-php.txt.

The following function are defined in nowsmsdlist.php:

<?php
// NowSMSDListExists - Returns true if distribution list exists, otherwise false.
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name

function NowSMSDListExists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListAction=List&DListName=" . urlencode($dlistName);
   $response = file_get_contents($urlString);
   if (!strncasecmp ($response, "OK", 2)) return true;
   else return false;

}

// NowSMSDListCheckMember - Returns true if member of distribution list, otherwise false.
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name
//  $dlistMember - Distribution list member phone number

function NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName, $dlistMember) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListAction=List&DListName=" . urlencode($dlistName);
   $response = file_get_contents($urlString);

   $memberArray = explode("\r\n",$response); 

   for ($i = 1; $i < count($memberArray); $i++) {
      $idxDash = strpos ($memberArray[$i], " -");
      if ($idxDash !== false) {
         $memberArray[$i] = substr ($memberArray[$i], 0, $idxDash);
      }
      if (!strcasecmp ($memberArray[$i], $dlistMember)) return true;
   }

   return false;

}

// NowSMSDListAddMember - Add member to distribution list
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name
//  $dlistMember - Distribution list member phone number

function NowSMSDListAddMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName, $dlistMember) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListMemberAction=Add&DListName=" . urlencode($dlistName) . "&DListMember=" . urlencode($dlistMember);
   $response = file_get_contents($urlString);

}

// NowSMSDListDeleteMember - Delete member from distribution list
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name
//  $dlistMember - Distribution list member phone number

function NowSMSDListDeleteMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName, $dlistMember) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListMemberAction=Delete&DListName=" . urlencode($dlistName) . "&DListMember=" . urlencode($dlistMember);
   $response = file_get_contents($urlString);

}

// NowSMSDListDeleteMemberAllLists - Scan all distribution lists and remove member
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistMember - Distribution list member phone number

function NowSMSDListDeleteMemberAllLists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistMember) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/DLists?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "DListAction=List";
   $response = file_get_contents($urlString);

   $dlistArray = explode("\r\n",$response); 

   // Loop through all distribution lists and remove member
   for ($i = 0; $i < count($dlistArray); $i++) {
      if ($dlistArray[$i] != "") {
         if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistArray[$i], $dlistMember)) {
            NowSMSDListDeleteMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistArray[$i], $dlistMember);
         }
      }
   }

}

// NowSMSDListSendSMS - Send an SMS text message to a distribution list
// Parameters:
//  $nowsmsIP - IP Address or host name of NowSMS server (127.0.0.1 for local host)
//  $nowsmsPort - Web interface port number of NowSMS server (8800 for default configuration)
//  $nowsmsUser & $nowsmsPassword - user name and password for account defined under "SMS Users"
//  $dlistName - Distribution list name

function NowSMSDListSendSMS ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $dlistName, $smsText) {

   $urlString = "http://" . $nowsmsIP . ":" . $nowsmsPort . "/?";
   if (!is_null($nowsmsUser) && ($nowsmsUser != "")) {
      $urlString = $urlString . "User=" . urlencode($nowsmsUser) . "&Password=" . urlencode($nowsmsPassword) . "&";
   }
   $urlString = $urlString . "PhoneNumber=" . urlencode($dlistName) . "&Text=" . urlencode($smsText);
   $response = file_get_contents($urlString);
   if (strpos ($response, "MessageID=") === false) return false;
   else return true;

}
?>

<?php

header ("Content-Type: text/plain"); 

// dlist-example.php - This is an example to describe PHP functions for adding and deleting members from an SMS distribution list.
//
// Expected 2-way command format:  http://server/dlist-example.php?sender=@@SENDER@@&text=@@FULLSMS@@
//
// This example supports receiving the following commands via SMS:
//   "JOIN dlistname" or "START dlistname" to join a distribution list
//   "STOP dlistname" or "LEAVE dlistname" to be removed from a distribution list.
//   "STOP" by itself will remove the user from all distribution lists.
//   "SEND dlistname " allows any member of the distribution list to broadcast a message to the entire list.

$nowsmsIP = "127.0.0.1";
$nowsmsPort = "8800";
$nowsmsUser = "test";
$nowsmsPassword = "test";

require_once "nowsmsdlist.php";   // PHP function file that contains functions for working with NowSMS distribution lists

/* Performs explode() on a string with the given delimiter and trims all whitespace for the elements */
function explode_trim($str, $delimiter = ',') {
    if ( is_string($delimiter) ) {
        $str = trim(preg_replace('|\\s*(?:' . preg_quote($delimiter) . ')\\s*|', $delimiter, $str));
        return explode($delimiter, $str);
    }
    return $str;
} 

// Check for required URL parameters, sender and text
// Expected 2-way command format:  http://server/dlist.php?sender=@@SENDER@@&text=@@FULLSMS@@

if (!isset($_REQUEST['sender'])) {
echo "ERROR : 'sender' parameter missing!\r\n";
exit();
}

if (!isset($_REQUEST['text'])) {
echo "ERROR : 'text' parameter missing\r\n";
exit();
} 

$array = explode_trim($_REQUEST['text'],' '); 

// If a list name was not specified, set array with blank value
if (count($array) < 2) $array[1] = "";

if (!strcasecmp($array[0],"JOIN") || !strcasecmp($array[0],"START")) {
   // Check if distribution list exists
   if (NowSMSDListExists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1])) {
      // Distribution list exists, check if sender is already a member
      if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
         echo "You have already joined list " . $array[1] . ".  Reply STOP " . $array[1] . " to leave.";
      }
      else {
         // Add member to distribution list
         NowSMSDListAddMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender']);
         // Verify that member was added to distribution list
         if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
            echo "You have joined list " . $array[1] . ".  Reply STOP " . $array[1] . " to leave.";
         }
         else {
            echo "An error occurred attempting to join list " . $array[1];
         }
      }
   }
   else {
      echo "List " . $array[1] . " does not exist.";
   }
}
else if (!strcasecmp($array[0],"LEAVE") || !strcasecmp($array[0],"STOP")) {
   // If a list name was not specified, remove from all lists.
   if ($array[1] == "") {
      NowSMSDListDeleteMemberAllLists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $_REQUEST['sender']);
      echo "You have been removed from all lists";
   }
   // Check if distribution list exists
   else if (NowSMSDListExists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1])) {
      // Distribution list exists, check if sender is a member
      if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
         // Remove member from distribution list
         NowSMSDListDeleteMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender']);
         // Verify that member was removed
         if (!NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
            echo "You are no longer subscribed to list " . $array[1] . ".";
         }
         else {
            echo "An error occurred attempting to leave list " . $array[1];
         }
      }
      else {
         echo "You are not subscribed to list " . $array[1] . ".";
      }
   }
   else {
      echo "List " . $array[1] . " does not exist.";
   }
}
else if (!strcasecmp($array[0],"SEND")) {
   // Check if distribution list exists
   if (NowSMSDListExists ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1])) {
      // Distribution list exists, check if sender is already a member
      if (NowSMSDListCheckMember ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $_REQUEST['sender'])) {
         $smsText = $array[1] . ":" . $_REQUEST['sender'];
         for ($i = 2; $i < count($array); $i++) {
            $smsText = $smsText . " " . $array[$i];
         }
         if (NowSMSDListSendSMS ($nowsmsIP, $nowsmsPort, $nowsmsUser, $nowsmsPassword, $array[1], $smsText)) {
            echo "Message sent";
         }
         else echo "Error sending message";
      }
      else echo "You are not subscribed to list " . $array[i] . ".";
   }
   else echo "Unknown list " . $array[i] . ".";

}
else {
   echo "Unknown request " . $array[0];
}

?>

These log files are stored on the NowWAP server, with one log file created for each day, using a file naming convention of WAPGW-yyyymmdd.LOG, where yyyymmdd is the 4-digit year, 2-digit month and 2-digit day.

NowWAP 2011 has optional functionality which can convert these log files into a database format for further analysis. This functionality is enabled by checking “Generate Usage Reports” on the “Reports” page of the configuration dialog.

When usage reports are enabled, NowWAP will automatically generate daily and monthly usage reports.

These reports are located in the REPORTS subdirectory of the NowSMS installation.

REPORTS\LOGDB contains SQLite format databases with one database per month.

REPORTS\TEXT contains text format summary reports of NowWAP usage. Daily reports have file names of YYYYMMDD.TXT and monthly reports have file names of YYYYMM.TXT. Every night at midnight, a new daily report and updated monthly report for the current month will be generated.

The format of the text report will be similar to the following:

NowWAP Usage Report: YYYYMMDD
#### - Max Active Users
#### - Max Active Requests
#### - Total Unique MSISDN
#### - Total Sessions
#### - Total Requests

Top Active Users
#### - Phone Number 1
#### - Phone Number 2
etc...

Top Content Domains
#### - Domain 1
#### - Domain 2
etc...

Top Content Servers
#### - Server 1
#### - Server 2
etc...

REPORTS\XML contains XML formatted summary reports of NowWAP usage. Daily reports have file names of YYYYMMDD.XML and monthly reports have file names of YYYYMM.XML. Every night at midnight, a new daily report and updated monthly report for the current month will be generated.

The format of the XML report will be similar to the following. Note that some XML elements may not be present, depending on NowWAP configuration issues. Also note that additional XML elements may be added in future releases.

<NowWAPUsageReport>
<ReportDate>YYYYMMDD</ReportDate>
<MaxActiveUsers>####</MaxActiveUsers>
<MaxActiveRequests>####</MaxActiveRequests>
<TotalUniqueMsisdn>####</TotalUniqueMsidn>
<TotalSessions>####</TotalSessions>
<TotalRequests>####</TotalRequests>
<TopActiveMsisdn>
<Name>Phone Number 1</Name><Requests>####</Requests>
<Name>Phone Number 2</Name><Requests>####</Requests>
</TopActiveMsisdn>
<TopContentDomains>
<Name>Domain 1</Name><Requests>####</Requests>
<Name>Domain 2</Name><Requests>####</Requests>
</TopContentDomains>
<TopContentServers>
<Name>Server 1</Name><Requests>####</Requests>
<Name>Server 2</Name><Requests>####</Requests>
</TopContentServers>
</NowWAPUsageReport>

ReportDate – YYYYMMDD for a daily report or YYYYMM for a monthly report.

MaxActiveUsers – The maximum number of active (concurrent) users recorded during the report period. (Note: This information cannot be obtained from log files created by earlier versions of NowWAP.)

MaxActiveRequests – The maximum number of simultaneous requests recorded during the report period. (Note: This information cannot be obtained from log files created by earlier versions of NowWAP.)

TotalUniqueMsisdn – The number of unique MSISDN (phone numbers) that made requests of the proxy. (Note: Requires MSISDN/RADIUS integration.)

TotalSessions – The number of user sessions during the report period.

TotalRequests – The number of user requests serviced during the report period.

TopActiveMsisdn – A list of the most active mobile terminals and the number of requests generated by that mobile terminal during the report period. (Note: Requires MSISDN/RADIUS integration.)

TopContentDomains – A list of the content domains which recorded the most requests (hits) during the report period.

TopContentServers – A list of the content servers which recorded the most requests (hits) during the report period.

Additional Reports

It may be possible to create additional reports by developing your own queries of the reports database.

Every day the log files from the previous day get merged into a monthly SQLite database format that is stored in the REPORTS\LOGDB directory.

It is possible to download SQLite from www.sqlite.org, and use sqlite3.exe to run queries against the database.

To better understand the database structure, here are the commands that are used to create the monthly database:

CREATE TABLE WAPGWLOG (AUTOID INTEGER PRIMARY KEY AUTOINCREMENT, RequestID text, RequestIP text, MSISDN text, RequestDate text, RequestTime text, RequestType text, RequestServer text, RequestDomain text, RequestURL text, HTTPStatus text, BytesOut integer, BytesIn integer, UserAgent text);
create index RequestID on WAPGWLOG (RequestID);
create index RequestDate on WAPGWLOG (RequestDate);
create index MSISDN on WAPGWLOG (MSISDN);
create index RequestDomain on WAPGWLOG (RequestDomain);
create index RequestServer on WAPGWLOG (RequestServer);
create index RequestType on WAPGWLOG (RequestType);
create index MSISDNByDate on WAPGWLOG (RequestDate,MSISDN);
create index RequestDomainByDate on WAPGWLOG (RequestDate,RequestDomain);
create index RequestServerByDate on WAPGWLOG (RequestDate,RequestServer);
create index RequestTypeByDate on WAPGWLOG (RequestDate,RequestType);

More information about database fields:

RequestID = auto generated ID for request
RequestIP = IP address of device
MSISDN = MSISDN of device
RequestDate format = YYYYMMDD
RequestTime format = HHMMSS
RequestType – GET, POST, CONNECT, DISCONNECT, STARTSERVICE, STOPSERVICE
RequestServer – Host name part of URL
RequestDomain – Host name parsed to higher level domain name
HTTPStatus – HTTP Status code of request (e.g, 200=OK, 301=Redirect, 304=Not Modified, 404=Not Found, etc.)
BytesOut, BytesIn – Number of bytes transferred to/from device
UserAgent – User-agent header from device making request

SQL Commands used to generate information in summary report:

Total Unique MSISDN

select count(*) from (select MSISDN from WAPGWLOG where (RequestDate = ‘%s’) and (MSISDN != ”) group by MSISDN);

Total Sessions

select count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (RequestType = ‘CONNECT’) and (RequestURL = ”);

Total Requests

select count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (RequestType != ‘STARTSERVICE’) and (RequestType != ‘STOPSERVICE’);

Top Active Users

select MSISDN,count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (MSISDN != ”) group by MSISDN order by count(*) DESC limit 100;

Top Content Domains

select RequestDomain,count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (RequestDomain != ”) group by RequestDomain order by count(*) DESC limit 100;

Top Content Servers

select RequestServer,count(*) from WAPGWLOG where (RequestDate = ‘%s’) and (RequestServer != ”) group by RequestServer order by count(*) DESC limit 100;

Some of this discussion can be found at the following message thread on the NowSMS discussion forum: http://www.nowsms.com/discus/messages/1/70053.html

This article attempts to summarise this information. Those interested in further information are encouraged to join the discussion thread.

Most NowSMS users will have no reason to be concerned with these parameters. This article is presented primarily for the interest of those using NowSMS as part of an SMS hub application.

Part of the inspiration for this discussion is the GSM Association document “Open Connectivity SMS Hubbing Architecture IR.75″, which can be found at the following link: http://www.gsmworld.com/documents/IR7520_unrest.pdf

That document suggests using the SMPP TLV parameters source_subaddress (0×202) and dest_subaddress (0×203) for encoding routing information for the MCC (mobile country code) and MNC (mobile network code) of the source (sender) and destination (recipient) addresses.

This is done to help simplify the routing of messages by intermediary hubs.

Historically, SMS service providers have defined their own proprietary SMPP TLV to encode this information (if it is made available at all). For example, mBlox defines an mblox_operator parameter using TLV parameter number 0×1402.

Hopefully more providers will use the GSM Association Recommendation in IR.75 in place of proprietary parameters.

Future versions of NowSMS (releases after 2011.05.05) will include automatically include support for forwarding these parameters.

Support can be enabled in prior versions of NowSMS by creating or editing an [SMPPOptions] section in SMSGW.INI and adding the following entries to this section:

[SMPPOptions]
source_subaddress=202,HexString
dest_subaddress=203,HexString

(Note: Support for the HexString parameter format was added in 2007.04.)

It is necessary to use the HexString encoding format for this parameter, because the SMPP specification defines first byte of the value as being a binary code value for the type of subaddress. In the case of the GSM Association values, this first byte is always A0 (hex), indicating user specified.

The next 3 bytes are the MCC, followed by 3 bytes for the MNC.

ASCII character values are used for the MCC and MNC, and then converted to a hex string.

The IR.75 document provides an example using the MCC and MNC for AT&T USA, where MCC=310 and MNC=380.

Converting the MCC value from ASCII to its hex string encoding would produce the following sequence of bytes: 33 31 30, and MNC would result in the following: 33 38 30.

The resulting parameter value in hex string format would be A0333130333830.

To specify this value as a source subaddress in NowSMS via HTTP, the following parameter value would be used:

SMPPOption_source_subaddress=A0333130333830

This thread discusses the use of NowSMS accounting callbacks, which can be used to query and/or update these parameters. (Update support was added in the 2011.04.17 release.)

Most NowSMS users will have no reason to be concerned with these parameters.

However, here are a few of the scenarios where it may be necessary to use these parameters.

1.) 2-way (interactive) SMS applications may receive the SMPPOption_source_subaddress parameter to indicate the mobile network from which the request originated, and be required to supply this value as the SMPPOption_dest_subaddress when generating a reply.

Future versions of NowSMS (releases after 2011.05.05) will apply this logic automatically when processing a 2-way command that returns its text response directly. Other 2-way commands would need to look for the “&SMPPOption_source_subaddress=” URL parameter and generate an appropriate “&SMPPOption_dest_subaddress=” URL parameter when submitting a message reply back to NowSMS.

2.) When NowSMS is being used to route messages between providers, it may be desirable to route messages based upon the MCC/MNC value.

This can be done via SMS accounting callbacks. This concept is described in the following article:

http://www.nowsms.com/dynamic-sms-message-routing-with-http-callbacks

What is not mentioned in that article is that beginning with release 2010.05.17, NowSMS also includes SMPP TLV parameters in the accounting callbacks.

This allows the callback processor to inspect the “&SMPPOption_source_subaddress=” and “&SMPPOption_dest_subaddress=” parameters, using those values to determine which route to use for sending the message. (The callback returns a response of SMSCRoute=xxxxx to specify the route to be used, as described in the link referenced above.)

3.) As an extension to the previous scenario, it may be necessary for a system providing SMS hubbing services to apply or insert the above values.

For example, it may be desirable to apply a source_subaddress automatically to all messages received from a particular connection.

Or it may be desirable to perform HLR lookups and apply dest_subaddress parameters before routing.

NowSMS 2011.04.17 and later allow these TLV parameters to be updated by an accounting callback.

In addition to passing these parameters to accounting callbacks via HTTP URL parameters, NowSMS checks the response from the accounting callback to allow these parameters to be set or updated.

The accounting callback should return a “text/plain” response with any parameters to be updated separated by line breaks.

For example:

SMSCRoute=connectionA
SMPPOption_source_subaddress=A0333130333830
SMPPOption_dest_subaddress=A0323334303135

Note: To enable the ability to override SMPPOption parameter values in the accounting callback response, it is necessary at this time to add SMSAccountingAllowChanges=Yes to the [SMSGW] section of SMSGW.INI.

One other note for those not familiar with the NowSMS concept of accounting callbacks. These are HTTP callbacks where NowSMS send an HTTP request to a URL that you define.

These callbacks would normally reside on a separate web server. However, newer versions of NowSMS also support the ability to host PHP scripts locally, as described in the following article: http://www.nowsms.com/now-sms-native-php-scripts

PHP scripts are often used for 2-way SMS or MMS processing, providing a convenient mechanism for processing the received message content in an application, and optionally replying back to the received message, updating or querying a database, or taking other action upon the message which could involve sending one or more messages to other parties.

PHP scripts are also frequently used to implement accounting or routing callbacks. Accounting callbacks can be used to record messaging activity, and to integrate with external billing or accounting systems. These accounting callbacks also support the ability to block messaging activity when external billing criteria indicates that a message operation should be be allowed. Routing callbacks can be used to provide additional control for selecting the outbound route to be used for message delivery, such as interfacing into mobile number portability databases or HLR lookups.

NowSMS interfaces with PHP scripts via an HTTP interface, which has historically required a separate HTTP web server with PHP installed. By using an HTTP interface, NowSMS can integrate with other web based scripting languages and environments, including ASP, ASP.Net, Java and Perl.

The separate web server requirement can make it more difficult to develop 2-way command scripts or accounting callbacks, especially when prototyping an application.

Beginning with the 2011.04.19 version of NowSMS (currently in test release at http://www.nowsms.com/download/nowsms20110419.zip), NowSMS supports the ability to interface with a locally installed copy of PHP, without requiring a separate web server to manage PHP callbacks.

To enable this support, it is necessary to first install PHP on the PC that is running NowSMS by following these steps:

1.) Download and run the Windows installer for PHP at http://windows.php.net/download/.  We recommend using a thread safe version of the current build (5.3.6 at the time this article was written).

2.) When the PHP installer displays its “Web Server Setup” selection screen, be sure to select “Other CGI”.

3.) The default PHP installation does not include many popular PHP libraries and extensions.  You may want to consider installing other “Extensions” and “Extras”.  At a minimum, we recommend installing PEAR, which is listed under “Extras”.   (In particular, the mail functions built into PHP are extremely limited, and the PEAR Mail Package is frequently used for sending e-mails from PHP scripts.)



4.) After PHP has been installed, let’s continue and install PEAR and the PEAR Mail package.  Open a Command Prompt window by right clicking on “Command Prompt” (usually under Programs/Accessories) and selecting “Run as Administrator”.  Once the Command Prompt window is open, change to the directory in which PHP was installed.

5.) To install PEAR, type go-pear and press Enter.  Unless you are an expert at installing and configuring PEAR, accept all of the defaults presented by the installation routine by pressing Enter each time prompted.

6.) To install the PEAR Mail Package, from that same command prompt window, type:

 pear install Mail

7.) Mail requires an additional PEAR package to function properly: Net_SMTP.  To install the PEAR Net_SMTP Package, from that same command prompt window, type:

 pear install Net_SMTP

8.) PHP installation is complete.  Now it is necessary to configure NowSMS to use the locally installed copy of PHP.  In the NowSMS configuration, go to the “2-Way” page, and select “Enable Local PHP Processing”.

NowSMS interfaces with php-cgi.exe, which should have been installed by the PHP installation program.  When “Enable Local PHP Processing” is first checked, NowSMS will verify that it can locate php-cgi.exe.  If it cannot locate this file, an error message will be displayed.

You are now ready to create your first PHP script.

What You Need To Know About NowSMS and Local PHP Scripts

The “2-Way” command page displays the directory location of the directory that should contain any local PHP scripts, as shown above, where it displays “http://nowsmslocal/php resolves to C:\ProgramData\NowSMS\PHP\”.

This indicates that PHP scripts need to be placed in the C:\ProgramData\NowSMS\PHP directory.  It is possible to change this directory by editing SMSGW.INI, and under the [SMSGW] header, adding PHPDir=c:\path

If, after adding a PHPDir= configuration parameter, the “2-Way” page does not update to the new location, uncheck “Enable Local PHP Process”, and then recheck this setting.

When defining a 2-way command (or accounting callback) that points to a local PHP script, the script URL should start with http://nowsmslocal/php (example for a script named echo.php: http://nowsmslocal/php/echo.php&sender=@@SENDER@@&text=@@FULLSMS@@).

It is also possible to access these PHP scripts from a web browser installed on the same machine by referencing the script via the local loopback address, http://localhost:8800/php or http://127.0.0.1:8800/php (assuming that the NowSMS web interface is running on port 8800, otherwise change this port number).  By default, PHP scripts can only be accessed locally.  If access required from other systems, check “Allow External Web Access to PHP Scripts”.  When “Allow External Web Access to PHP Scripts” is enabled, the scripts will be accessible to any system that can access the NowSMS web interface (i.e., the “Allowed/Blocked” list on the “Web” configuration dialog).

Let’s start with a simple 2-way command example.

echo.php is a simple PHP script that parses the text of a received message, and replies back with the same text:

<?php
header ("Content-Type: text/plain");
if (isset($_REQUEST['text'])) {
   $text = $_REQUEST['text'];
   echo $text;
}
else {
   echo "Invalid request, text= parameter expected.";
}
?>

This simple example provides a good starting point for building more complex 2-way commands.

Cut and paste the above script into a file named echo.php in your NowSMS PHP directory.

From a web browser on the same machine, access http://127.0.0.1:8800/php/echo.php.  A text page should be returned that says “Invalid request, text= parameter expected.”  This indicates that local PHP support is fully configured and operational.

Now let’s configure NowSMS to execute this command every time it receives an SMS message, sending an echo response back to the sender.

Before continuing, ensure that “Process received SMS Messages” is checked.

In the “SMS Command Prefix” field, enter a single asterisk character: *  This character is a wildcard, indicating that the command will match all received messages.  If you want to use this test script for a particular keyword match only (such as “echo”), then enter that keyword instead of *.

The “Receive Phone Number” field can be left blank for the purposes of this test.

“Command to Execute” should be http://nowsmslocal/php/echo.php?text=@@TEXT&sender=@@SENDER@@

This particular command returns its response directly in the script, so “Command returns response text” should also be checked.

Press “Add” to add the command to the table, and “Apply” to save changes.  Restart the NowSMS service.

The simple version of the echo.php script only checks the “text=” parameter, which is accessible in the script as $_REQUEST['text'].

Try sending an SMS message in to the script. If the “SMS Received” counter on the “Service” page of the NowSMS configuration dialog is not showing an increase in received messages, your messages are not making it as far as NowSMS.  There are some helpful troubleshooting tips for this situation in a post on the NowSMS discussion board at http://www.nowsms.com/discus/messages/1/4520.html.

Note that it is very dangerous to implement a script that blindly replies back to all received messages, as it is possible to get stuck in an infinite reply loop with other SMS robots.  It is advisable that you include logic in your script to limit replies, especially error replies.  Also, beware of loops where you accidentally send an SMS message from your modem to itself.  You can include a check at the beginning of a PHP script to guard against sending to yourself by checking the number from which the message was received, and make sure it does not match the sending number:

if (!strcmp($_REQUEST['sender'],”+447777777777″)) { return; }

This is a real simple example intended to help you get started.

Instead of replying back to the SMS message, your script can issue new requests back to NowSMS to send messages (see Send SMS from PHP Script and Send MMS Message from PHP Script for these examples).  Or your PHP script could query and/or update a database.  There are many possibilities.

Additional NowSMS PHP examples and information are available at the following links:

http://www.nowsms.com/faq/api

http://www.nowsms.com/tag/php

Additional resources for general PHP API information include:

http://www.php.net/

http://pear.php.net/

It started off simple enough.

If you send an MMS message using the simple web form in NowSMS, and you include some text and an image, the resulting message displays the text first and then the image.

What if you want the image displayed first and then the text?

Or what if you want the text to be displayed as a caption under the image, on the same page, instead of on a separate page?

The first scenario is simple to address. The second scenario is where you may require an aspirin.

Des did an excellent job of addressing the scenario of displaying the image first, and then the text:

NowSMS inserts objects in the order that they are presented.

Instead of using the text object, put the text in a file and attach that file after the image.

If you want more full control, you need to create your own SMIL and include it as one of the objects (use a .smil file extension).

If no SMIL is included, NowSMS auto generates some simple SMIL that presents one object per page in the order in which the objects were attached.

If only Des didn’t mention SMIL. He could have left the answer simple and moved on to another question.

But that is not our way.

So what exactly is SMIL?

SMIL is a presentation language that is used to configure how an MMS message is displayed, similar to how HTML is a presentation language that is used to configure how information on a web page is to be displayed.

However, while HTML is a very powerful and flexible presentation markup language, SMIL is a very simplistic and limited presentation markup language. And MMS SMIL, which is a subset of Basic SMIL, which is a subset of SMIL, is even more limited still.

I like to think of SMIL as a simple presentation language for slide show presentations. SMIL organizes the slides, or pages, of an MMS message presentation. Sort of like PowerPoint, but again, much more limited.

Have I emphasized enough that SMIL, especially MMS SMIL, is very limited? So don’t expect to wow your audience with complex charts and graphics.

Before we dive further into SMIL, let’s backup and look at what an MMS message is.

An MMS message is very similar to an e-mail message, in many ways you can think of MMS as an e-mail system designed for mobile phone networks. (Looking for more information on the transport level implementation? If so, see our article How MMS Works).

Like an e-mail message, an MMS message has a header that contains information such as who the message is “From” and who it is “To”, along with a “Subject”.

The content of an MMS message is a collection of one or more multimedia objects, such as text, image, video and audio. MMS messages can also contain other objects such as address cards (vCards), calendar appointments (vCal), Java applications, and more, if supported by the MMS client on the mobile phone. But for the most part you are dealing with one or more text, image, video and/or audio objects.

If you think of an e-mail message, you think of a text object, along with zero or more attachments.

Or, a more modern e-mail message might be HTML formatted, so that the multimedia objects are automatically displayed when the e-mail message is opened.

Similar to HTML being used in an e-mail message, an MMS message should always have a SMIL presentation part which determines how the MMS message is displayed. (If a SMIL presentation is not included in an MMS message, many operator MMS systems will automatically generate SMIL and add it to the message before it is received by the recipient.)

When included in an MMS message, a SMIL presentation becomes one of the objects within an MMS message. A typical MMS message that contains text and an image would have three objects contained in the MMS message, a SMIL object, a text object and an image object.

Let’s stop using the word object. When building an MMS message, an object is a file. So our typical MMS message with text and an image has three separate files that are the content of the MMS message, a SMIL file, a text file and an image file (e.g., PNG, JPEG, GIF).

One important conceptual difference between SMIL and HTML is that there is no in-line text within a SMIL presentation. If you want to include text in a SMIL presentation, you include a reference to a separate text object/file.

Another important conceptual difference is that you have to consider the relatively small screen of most devices that will be receiving MMS messages.

For all practical purposes, you should not include more than one of the same type of object in a single page (slide) of the SMIL presentation. This means more than one image on a page is generally not recommended because of the limitations of most devices. More than one text object on a page is also not recommended.

The MMS Conformance Document from the Open Mobile Alliance goes into more detail. Basically each page of a SMIL presentation can have no more than two regions, an image region and a text region. The image region can have a single image or a video. The text region can have a single text object. An audio object can play while the page is being displayed.

That’s really all there is to it. Full SMIL has capabilities like setting text and background colors, however the subset that is MMS SMIL, as defined in the MMS Conformance Document, does not include those attributes.

Let’s go back to our original scenario, sending an MMS message that includes text and an image.

The Send MMS Message web form (and the NowSMS Proprietary URL API) include a single text field and zero or more files to include in the message.

When NowSMS processes the web form, if a text field is present, NowSMS automatically converts the text field into a text file to be included as the first object in the MMS message.

If a SMIL file is not included among the files to be included in the message, NowSMS automatically generates one.

For the widest compatibility with different devices, the default SMIL that NowSMS generates has one object per page. If the text field was used in the submission, it becomes the first page. Other pages are generated based upon the order in which objects were included in the submission.

The default NowSMS SMIL will typically look like this:

<smil>
<head>
<layout>
<region id="Image" height="100%" width="100%" fit="meet"/>
<region id="Text" height="100%" width="100%" fit="scroll"/>
</layout>
</head>
<body>
<par dur="3s">
<text src="filename.txt" region="Text"/>
</par>
<par dur="5s">
<img src="image.jpg" region="Image"/>
</par>
</body>
</smil>

The start of the SMIL is a header and opening for the body section:

<smil>
<head>
<layout>
<region id="Image" height="100%" width="100%" fit="meet"/>
<region id="Text" height="100%" width="100%" fit="scroll"/>
</layout>
</head>
<body>

The layout section defines two regions, as instructed by the MMS Conformance Document. For simplicity, NowSMS automatically generated SMIL says that either section can take up the entire height and width of the page. Images are scaled to “meet” the size of the screen, while text is allowed to “scroll” if it is too large.

More complex region layouts can be designed, but the MMS Conformance Document states that an MMS Client may choose to replace the layout section with its own terminal specific layout, so we have yet to see the point of such an effort.

Each page of the SMIL presentation is represented by a <par> section:

<par dur="3s">
<text src="filename.txt" region="Text"/>
</par>

<par dur="5s">
<img src="image.jpg" region="Image"/>
</par>

text, img, video and audio tags with a src parameter define objects that appear in the MMS message. You’ll see text and img tags in the above example. The src parameter of one of these object tags refers to another content object/filename that is included in the message. Unlike HTML format e-mails, you cannot reference content by an external HTTP link. Any content referenced by your SMIL must be a file that is included in the MMS message content.

The “dur” parameter for the <par> element specfies how long a particular slide is displayed.

In this example, the text that was submitted as part of this MMS message was included in a text file named filename.txt. The image was an image file named image.jpg.

When submitting files to be included in an MMS message with NowSMS it is important to use common filename extensions such as .txt and .jpg. This is because when NowSMS packages the files into an MMS message, NowSMS needs to specify the MIME content type of the files. NowSMS uses the filename extension to MIME content type mappings defined in the MMSCTYPE.INI file that is in the NowSMS program directory.

Finally, the SMIL is concluded with tags to close the presentation:

</body>
</smil>

It is easy to override the automatically generated SMIL by creating your own SMIL. You then include this SMIL as one of the content objects in your MMS message. (Again filename extensions are important …. be sure to give the file a “.smil” file extension, so that NowSMS will recognise it as such.) All “src=” references within your SMIL should be for filenames of other files that are being included in the MMS message.

For example, to have the image and text display on a single page, you could do make this change:

<smil>
<head>
<layout>
<region id="Image" height="100%" width="100%" fit="meet"/>
<region id="Text" height="100%" width="100%" fit="scroll"/>
</layout>
</head>
<body>
<par dur="5s">
<text src="filename.txt" region="Text"/>
<img src="image.jpg" region="Image"/>
</par>
</body>
</smil>

When submitting the MMS message, you would need to include the SMIL file, along with filename.txt and image.jpg.

You could also change the “%” of height for the text and image regions for best results, but be aware that a lot of MMS clients will ignore it.

Also note that when you generate your own SMIL, you should include any text objects as separate files, not using the “MMS Text” parameter of the NowSMS web interface. This is because NowSMS automatically converts the “MMS Text” into a file, but it generates a temporary name for the text file, so it is not possible to reference this text in your SMIL

There is more discussion back on the discussion board thread MMS: first shows a picture and then the text, but hopefully this discussion is more digestable as a simple tutorial for creating your own SMIL in an MMS message.

For more information, I highly recommend referring to the MMS Conformance Document from the Open Mobile Alliance, which can be found at the following location: http://openmobilealliance.org/Technical/release_program/mms_v1_2.aspx.

The full SMIL 2.0 specification can be found at http://www.w3.org/TR/2005/REC-SMIL2-20050107/.

When a certificate is issued by a certificate authority by an intermediate certificate, it is necessary to install not just your certificate on the server, but additionally it is necessary to install the certificate chain for the CA’s intermediate certificate.  This certificate chain will be provided by the certificate authority along with your signed certificate.

At this time, an updated version of SMSSSL.DLL is required to support an SSL certificate chain.  An update can be downloaded at http://www.nowsms.com/download/smssslchain.zip.  To install the update, stop the NowSMS services and exit the NowSMS program.  Next, update the SMSSSL.DLL file in Program Files (or Program Files (x86)) \ NowSMS with the version in this ZIP file.

Locate the directory that contains your SSL certificate request (SSL.CSR).  This is either the ProgramData\NowSMS directory (Windows 7/Vista/2008) or Program Files\NowSMS (XP/2003) directory.

Using a text editor, such as NOTEPAD.EXE, create or edit a file named SSL.CA, which is the filename designated to contain your signed SSL certificate.  Your signed certificate should be placed at the start of this file, including the —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– markers.  Following  your signed certificate, you should include any intermediate certificates in this same text file.  If there are multiple intermediate certificates, they should be ordered in the path from your server certificate toward the root CA certificate.

The NowSMS service must be restarted after updating an SSL certificate file in order for the new certificate to take effect.

In most cases, this is possible.  The NowSMS MMSC is designed with minimal administration requirements and automatic subscriber provisioning.  For a typical mobile operator configuration, subscribers are automatically provisioned to the NowSMS MMSC the first time a user sends an MMS message.   The following article explains how to configure this:  http://www.nowsms.com/nowsms-operator-mmsc-considerations

Automatic subscriber provisioning works great for a new MMSC installation, but what if you are replacing an existing MMSC that already has provisioned subscribers?

In some cases, it is not required that subscribers be provisioned on the NowSMS MMSC at all.  If the “Default Route” for MMS message delivery, or an explicit route defined just for your subscribers, is configured as “Direct Delivery“, then the MMSC will deliver MMS messages to subscribers whether or not they have been provisioned.

The above approach is used by some smaller mobile operators, but most operators prefer to only deliver MMS messages to subscribers that have been provisioned.  In this case, non-provisioned subscribers receive MMS messages that have been converted into an SMS format with a web link for accessing the multimedia content.  Configuring this option is described in the following article:  http://www.nowsms.com/mms-conversion-to-sms-with-web-link

In this case, you will want pre-provision your MMS subscribers in the NowSMS MMSC, so that they will receive MMS messages in normal MMS format, without the SMS conversion … and without requiring the subscribers to first send an MMS message to provision their account on the NowSMS MMSC.  There is an HTTP interface available for provisioning MMS subscribers which is described in the following article: http://www.nowsms.com/provisioning-sms-and-mmsc-user-accounts-via-http.

There is an additional alternative that is useful for bulk MMS subscriber provisioning, which is the MMSUSER.EXE command line utility.  MMSUSER accepts a text file that has a list of subscriber phone numbers.  The format of this file should contain one subscriber phone number per line, prefixed by “A,” which indicates that the subscriber should be added (conversely “D,” means the subscriber should be deleted).  For example:

A,+441111111111
A,+441111111112
A,+441111111113
A,+441111111114

Assuming that the file containing the list of subscribers in this format is called subimport.txt, run the following command from a command line prompt in the Program Files\NowSMS directory:

mmsuser -import subimport.txt

Additional information of interest to customers planning or considering an MMSC migration/replacement:

• MMSC Accounting Callbacks for Billing and Charging
• MM4 Interconnection Basics for exchanging MMS with other mobile operators
• Mobile Number Portability (MNP) and the NowSMS MMSC
• Detecting Roaming Subscribers

And for operators using CDMA based technologies, also see:

• MMSC in CDMA and CDMA2000 Environments

Another frequently asked question regards the role of the WAP Push Proxy Gateway (PPG).  The NowSMSC MMSC includes an integrated PPG that sends WAP Push messages using an SMS bearer, and there is not a requirement for a separate PPG.  However, for specialised configurations, it is possible to configure the NowSMS MMSC to use an external PPG, which is described in the following article:  http://www.nowsms.com/routing-mms-notifications-via-a-wap-push-proxy-gateway

It is also possible to use NowSMS as a PPG for other applications, as described in the following article:  http://www.nowsms.com/using-nowsms-as-a-wap-push-proxy-gateway-ppg

Basic HHE allows the subscriber to be identified by their MSISDN.

Aliased HHE allows the subscriber to be identified without divulging the subscriber’s MSISDN.

A standard feature of the NowWAP Proxy is to provide Basic HTTP Header Enrichment to facilitate operator billing for HTTP based services, including Multimedia Messaging Services (MMS).

Basic HHE is enabled for all subscriber HTTP transactions that are forwarded to a configurable list of content provider hosts and/or domains (most frequently these are hosts within the operator domain, such as the operator MMSC). Depending on the information available from the RADIUS accounting feed, this basic information can include the subscriber MSISDN, SGSN IP Address, SGSN MCC & MNC (useful for determining if the client is currently roaming), client IP address (useful for identifying which operator APN was accessed), IMSI, and radio access type (4G, 3G or 2.5G) .

Basic HHE can result in the following HTTP headers being inserted:

X-MSISDN: xxxxxxxxxxxxxxxxx
X-WAP-3GPP-SGSN-MCC-MNC: xxxxx
X-WAP-3GPP-SGSN-ADDRESS: 1.2.3.4
X-WAP-3GPP-IMSI: xxxxxxxxxxxxxx
X-WAP-3GPP-RAT-TYPE: 1 or 2 (1 = 3G, 2 = EDGE/GPRS) X-WAP-Client-IP: 7.8.9.0

The list of content provider hosts and/or domains that receive this basic HHE is configurable. Host names can be listed here explicitly, such as mmsc.operator.com, or all hosts within a particular domain can be included by adding the domain name to the list prefaced with a “.”, for example .operator.com means that all hosts within the operator.com domain would receive basic HHE (for example, both www.operator.com and mmsc.operator.com).

In many instances, it is useful to provide similar identifying information to content provider partners, but without divulging the subscriber MSISDN. A new feature of the NowWAP Proxy 2011 release is to provide Aliased HTTP Header Enrichment to meet this need.

Content provider hosts and domains that are to receive Aliased HHE are configured with a list that is similar, but separate from, the existing Basic HHE content provider domain/host list that is configured on the “MSISDN” page of the NowWAP configuration program.

NowWAP does not directly generate the Aliased HHE. Instead, it provides an HTTP callback interface to allow the customer to generate customized Aliased HHE that is appropriate for the target operator environment.

A customer-defined Aliased HHE callback interface is defined to NowWAP by adding the following configuration setting to the [WAPGW] header of WAPGW.INI: HHECallbackURL=http://server/path

When the HHE callback is configured in NowWAP, each time NowWAP receives a RADIUS notification of a new user connecting, NowWAP will make an HTTP GET request to the HHE callback to request HHE/alias information for the user account.

The HHE callback request will include MSISDN, and other RADIUS information, if available.

Example:

http://server/path?PhoneNumber=xxxx
&UserName=xxxxx
&AssignedIP=a.b.c.d
&3GPP-SGSN-MCC-MNC=xxxxx
&3GPP-SGSN-ADDRESS=xx
&3GPP-IMSI=xxxxxxxxxxxxxxx
&3GPP-RAT-TYPE=x

(Line breaks have been inserted in the URL above for readability only. There are no line breaks in the actual HHE callback URL.)

The “PhoneNumber” (MSISDN) and “AssignedIP” (X-WAP-Client-IP) parameters will always be present.  The 3GPP parameters would be present only if they were presented to NowWAP by the RADIUS feed.

The HHE callback response should be a text response containing enriched HTTP headers to be included in all requests that are processed on behalf of this device.  Example:

HTTP/1.1 200 OK
Content-Type: text/plain

X-MSISDN-Alias: xxxxxxxxxxxxxxxxxxxxx
X-HHE-Extra-Info: xxxxxxxxxxxxxxxxxxxxx

As NowWAP processes subsequent requests, if the request is directed to a content domain that receives Aliased HHE, these headers would be included in the HTTP request that is forwarded to the content provider. (Basic HHE would not be forwarded to these content providers.)

The list of content domains to receive Aliased HHE is defined in the WAPGW.INI file, under the [WAPGW] header, using keyword value pairs of the following format:

IncludeHHEForDomain1=.domain1.name
IncludeHHEForDomain2=host.domain2.name
IncludeHHEForDomain3=host.domain3.name

Host names can be listed explicitly, such as www.contentprovider.com, or all hosts within a particular domain can be included by adding the domain name to the list prefaced with a “.”, for example .contentprovider.com means that all hosts within the contentprovider.com domain would receive aliased HHE (for example, both www.contentprovider.com and www2.contentprovider.com).

Over the years, we’ve added a few comments to clarify how the script is to be used.  However, one of the most limiting things about the script is that it doesn’t support any of the additional SMS URL parameters supported by NowSMS.

Among other uses, these parameters might be needed in order to specify the SMSC Route to be used for sending the message, or specifying a sender address.

An updated SendSMS.php script, which supports additional URL parameters is available at http://www.nowsms.com/download/sendsms2-php.txt.

In the original script, we provided the following example for calling the SendSMS PHP function:

$x   = SendSMS("127.0.0.1", 8800, "username", "password", "+44999999999", "Test Message");

The new script supports the above format, but can also support additional optional parameters, specified in “parameter=value” format.  For example, the following example specifies an explicit outbound SMSC route and a sender address to be used.

$x   = SendSMS("127.0.0.1", 8800, "username", "password", "+44999999999", "Test Message",
 "SMSCRoute=Test", "Sender=1234");

For additional usage information regarding this PHP script, please refer to the original discussion of sendsms.php at http://www.nowsms.com/nowsms-php-example-send-sms-text-message.

For more information about NowSMS URL parameters, see http://www.nowsms.com/doc/submitting-sms-messages/url-parameters.

The updated SendSMS.php script is available at http://www.nowsms.com/download/sendsms2-php.txt.

Our investigation suggests that this problem is related to a software issue in the iPhone MMS client, when operating outside of 3G coverage.  There is no problem in the operation of either the NowWAP Gateway or the NowSMS MMSC.

(Note:  Problems with accounting callbacks and routing callbacks in the NowSMS MMSC can cause similar sporadic problems if the web server hosting the callbacks has problems with HTTP Keep-Alive sockets.  To rule out this being a problem, we recommend editing MMSC.INI, and under the [MMSC] header, add RoutingKeepAlive=No and AccountingKeepAlive=No.)

The iPhone appears to have an overall maximum timeout for sending an MMS message.  If it cannot send the entire content of the MMS message within this timeout period, it aborts the attempt and returns an error indication to the sender.   It is unclear exactly how the iPhone determinates this timeout value, as our tests suggest that it is somewhat variable and ranges between 2-1/2 and 3-1/2 minutes.

If an MMS message cannot be transmitted within this timeout period, the iPhone gives up, and automatically initiates a second attempt, and if that attempt fails with a similar timeout error, it returns the dreaded red “!” to indicate that the message sending failed.  If this type of timeout error has occurred, the red “!” will be returned after 5 to 7 minutes.
This problem is not likely to occur in 3G or HSPA coverage areas, but is more likely to happen in 2.5G coverage areas, especially areas that only have GPRS, but not EDGE, or areas with weaker signal strength, because the data upload speeds are slower, and it takes longer to transmit a message.

It appears that iOS 4.x will generally try to send larger image sizes in MMS messages than previous releases.  During testing, we found that one of the test images that we were sending, taken with the iPhone 4 camera, was 950KB in size.   In order to send a 950KB message in 2 minutes or less, the network must be able to provide an average upload speed of 80 Kbps, which is possible with a strong EDGE class 10 connection (max possible upload speed is 118Kbps), but not with GPRS (max possible upload speed is 40Kbps).

Note:  When the iPhone is connected with EDGE, it should “E” next to the operator name, instead of “3G”.   If the phone is connected with GPRS only, a dot is shown instead.

Depending on operator configuration, the iPhone advertises itself to the MMSC as supporting a maximum message size of 1MB (UAProf = http://www.apple.com/mms/uaprof.rdf) or 2MB (UAProf = http://iphonemms.apple.com/iphone/uaprof-2MB.rdf)

To rule out any issues potentially related to either NowWAP or the NowSMS MMSC, these same timeout values were observed testing standard issue operator locked iPhones on O2 in the UK and AT&T in the USA with 3G mode disabled on the phone.

Note that in jailbroken iPhones, it is possible to configure a “MMS Max Message Size” in the “Cellular Data Network” settings.  We experimented with lowering this value, however it appeared that when this value was lowered, if a message was going to exceed this size value, the iPhone would quickly fail the message with a red “!”, without actually attempting to send the message.  (Based upon these brief tests, it is not clear what algorithm the iPhone uses to scale down a picture before sending, as the 950KB picture that we referenced above actually has a native size of 2.7MB, and was taken with HDR enabled.)

The bottom line appears to be that sending pictures via MMS will frequently fail if the iPhone 4 is operating in a 2.5G (“E” for EDGE or a dot for GPRS) environments.  The problem is due to a sending timeout implemented in the MMS client software in the device.  This problem can only be resolved by changing this timeout in the MMS client software implementation, or changing the MMS client to have an option to send lower resolution pictures when operating in 2.5G environments.  There does not appear to be any solution that can be implemented on the mobile operator side.

To avoid frustration, it is recommended that users avoid sending picture or video messages when operating outside of a 3G coverage area.

Messages longer than 70 characters can, of course, be sent, but they are sent as multipart (segmented) messages, and reassembled by the receiving client.  If a message that contains Unicode characters is longer than 70 characters, it is broken into segments of 67 characters for sending.  To send a 160 character message requires 3 SMS messages if the message contains characters that are not part of the GSM character set.

The original GSM protocol was developed in Western Europe, so it includes most Western European characters, plus capital letters in the Greek alphabet in order to facilitate Greek SMS support.  You can view a table of characters in the GSM character set at the following link:  http://www.nowsms.com/long-sms-text-messages-and-the-160-character-limit

A recent posting on the NowSMS Technical Forums discusses recent developments in the 3GPP specifications to add additional national language support to the SMS standard, and eventually overcome these limitations.  For additional discussion of this topic, we recommend joining the discussion at http://www.nowsms.com/discus/messages/1/69650.html.   The start of this discussion is highlighted below.

Question:

I have a question about sending SMS messages using Turkish national characters. Specifically, these characters are a problem:

Ğ, ğ, Ş, ş, İ, ı, ç (upper case Ç is ok?)

I can send messages that contain these characters ok, but NowSMS encodes the messages with Unicode. This means if I send a message longer than 70 characters, it costs me to send two or more messages … instead of normal 160 character limit.

But in Turkey I have heard that there is a way to send these national characters without forcing the whole message to use Unicode encoding. I do not know how it works, but I have heard that this feature is called a locking shift table. Instead of the standard GSM 7-bit character table, mobile phones in Turkey must support a locking shift table that replaces the GSM characters with national characters for Turkey.

Can NowSMS support this SMS locking shift table?

Response:

The fact that messages that contain characters outside of the GSM character set require Unicode encoding and are limited to 70 characters per message instead of the expected 160 character limit, is indeed frustrating for many languages.

The shift tables that you mention are a relatively new development. There is a concept of a locking shift table that replaces the GSM 7-bit character set, and a single shift table which provides additional characters.

You are correct that these shift tables can replace and extend the default GSM 7-bit character set table so that more national characters can fit into a single SMS.

We’ve received a number of inquiries from handset testing labs about them, but I’m not sure that they are used in production systems. (Perhaps they are in active use in Turkey as I can see that there was national legislation there that prompted the 3GPP to develop a solution.)

In addition to Turkey, there are shift tables defined for the Spanish and Portuguese languages. These were all added in 3GPP release 8 (3GPP TS 23.038 and 23.040), which only started being released in 2008.

The Spanish shift table adds ç, Á, Í, Ó, Ú, á, í, ó, and ú.

The Portuguese shift tables add support for the following national language characters: Á À Â Ã ª á à â ã É Ê é ê Í í Ó Ô Õ º ó ô õ Ú Ü ú ü ` ç ∞

3GPP Release 9 adds 10 shift tables for languages of the Indian subcontinent: Bengali, Gujarati, Hindi, Kannada, Malayalam, Oriya, Punjabi, Tamil , Telugu, and Urdu.

Update:  Shift table support is now available in NowSMS.  Additional information and discussion is available at the following link:  http://www.nowsms.com/discus/messages/1/70000.html.

The reason for this seems to be some unusual communication patterns between the handset and the App World server. The handset attempts to created a tunneled connection to the HTTP port (80) of the BlackBerry App World server.

Symptoms of the problem include numerous 403 errors for connections to appworld.blackberry.com:80, similar to the WAPGW-yyyymmdd.log entry below:

10.3.4.63 50373060234 [26/Oct/2010:15:39:45 -0600] "CONNECT appworld.blackberry.com:80" 403 0 "" ""

The default configuration of NowWAP only allows tunneled connections to the HTTP SSL/TLS port (443).

It is possible to override this default configuration, and allow the connection by applying the following setting on the “HTTP” page of the NowWAP configuration: “Allow SSL/TLS Tunnel to non-standard ports”.

Enabling this setting will resolve the problem and allow users to connect to BlackBerry App World.

There are no security concerns involved with enabling this setting. If there are any concerns, they are commercial concerns. Most mobile operators have different APNs that provide different levels of connectivity. The default setting for NowWAP allows only standard web browsing to pass through the proxy. Enabling this setting could allow other applications to function through the proxy by allowing tunnels for other port numbers.

Future versions of NowWAP will include port 80 as an allowed tunneling port to avoid conflicts with the BlackBerry App World service.

In simplistic terms, an SMSC manages SMS messages for a mobile operator network, delivering SMS messages to mobile phones.

An ESME is any other type of entity that wants to exchange SMS messages with these mobile subscribers.  In other words, it is any type of application or service that wants to be able to send and/or receive SMS messages. These applications or services are also often referred to as Value Added Services (VAS) or Value Added Service Providers (VASP).

The SMPP protocol is designed to facilitate the exchange of these SMS messages over the standard TCP/IP protocol.

SMPP is designed to be fast and efficient to facilitate high volume reliable message exchange.

This page is designed to be a quick resource for more information on SMPP.  The following links provide more detailed information on specific issues or considerations regarding SMPP (especially for users of NowSMS):

• SMPP Version 3.4 Protocol Specification – This is the version of the SMPP specification that is in widespread use.  There is a later version 5.0 specification that was defined, but it did not have significant market acceptance, and the group that defined the later version specification has been disbanded.
• SMPP Version 3.3 Protocol Specification – A few mobile operators still use old SMSCs that implement the version 3.3 specification.  They can be challenging to work with as some areas of the version 3.3 specification are even more vague than version 3.4.
• Connecting to an SMPP SMSC – Connecting to an SMSC using SMPP can be confusing because of unusual terminology like TON, NPI, and service type.  It can also be confusing because there are many key areas of the SMPP specification that are vague, and different providers have decided to implement things different ways, especially with regard to character set encoding.  This link explains how to configure an SMSC connection in NowSMS, and includes a discussion of some of the terminology and configuration options.
• SMPP Character Set Issues: Long Text Messages and Unicode – Some SMPP implementations want you to submit a long message in a single submission, others require you to perform message segmentation based upon the message type (sometimes using TLV parameters, sometimes using GSM UDH).  Some SMPP implementations use the GSM character set, others use iso-8859-1.
• What are TON and NPI Settings? – TON (Type of Number) and NPI (Numbering Plan Indicator) are two of the settings that can easily give you a headache.  This link provides more information on these settings.
• Optional TLV Parameters – The SMPP Protocol is extensible in that it allows providers to add their own additional parameters, which are known as TLV parameters, so named because of the format of these parameters … Tag, Length, then Value.   Some TLV parameters are defined in the specification, but are optional and are sometimes used and sometimes not used.  Other parameters are provider specific.  This link helps you learn more about TLV parameters by explaining how to configure NowSMS to support custom TLV parameters for a provider.
• SMPP Error Code Reference – What do the error numbers or obscure terms like ESME_RTHROTTLED mean?  Use this link as a quick reference.
• SMPP Error Handling in NowSMS – This link explains how NowSMS handles different SMPP errors, and how can this behaviour be modified.
• Limiting the Speed of an SMPP Connection – SMS providers limit the speeds at which they will accept messages in order to optimise their resource allocation.  If you try to send faster than your provider allows, you may encounter unexpected errors and delays.
• Understanding SMPP Connection Types – Are you both sending and receiving messages?  Does your provider expect you to establish separate sender and receiver connections, or do they expect you to connect as a single connection transceiver?
• Using NowSMS as an SMPP Server for Other Applications – One of the more common uses of NowSMS is to use NowSMS as an SMPP server.  Other clients or applications connect to NowSMS as their SMPP Server, and NowSMS chains to one or more other SMSCs for sending and receiving SMS messages, possibly using SMPP, or possibly using other protocols.
• SMPP Asynchronous Mode – If you’re sending faster than 10 SMS messages per second, you  need to understand SMPP asynchronous mode.
• NowSMS Tech Support Blog – This link will display SMPP related posts on the NowSMS Tech Support Blog.
• NowSMS Technical Forum / Discussion Board – Additional discussions of SMPP related topics and issues take place on the NowSMS Technical Forum / Discussion Board.  Feel free to search these discussions and/or post questions.

One more thing …

As I wrote this post, I recalled one other bit of SMPP terminology that can drive new users crazy … MO and MT messages.  Some people like to throw these terms around just to pretend they know what they are talking about.

MO – Mobile Originated message … in other words, a message that has been sent by a mobile phone subscriber.

MT – Mobile Terminated message … in other words, a message that is destined to be delivered to a mobile phone subscriber.

When you are an application provider that is connecting to an SMS service provider, you receive MO messages, and you send MT messages.

If you would like more information on interfacing your application to NowSMS for SMS message processing, please refer to our API guide at:  http://www.nowsms.com/faq/apis-apis-apis-more-apis

The primary API for sending and receiving SMS and MMS messages with NowSMS is HTTP-based. Because the API is HTTP based, applications that wish to send or receive messages via NowSMS do not have to run on the same physical server, they can interface with NowSMS over a network.

This page contains links to additional information that describes the raw HTTP interface, as well as links to example scripts for PHP, Java and command-line interfacing with NowSMS.

Note that in addition to these APIs, NowSMS also supports the SMPP protocol, allowing SMS clients to connect to NowSMS as an SMPP server for both sending and receiving SMS messages. For MMS clients, NowSMS also supports the MM1, EAIF, MM3 (SMTP), MM4 and MM7 protocols for both sending and receiving MMS messages.

HTTP Protocol Information

• Sending SMS Text Messages over HTTP

• Sending WAP Push Messages over HTTP

• Sending WAP Push Messages using PAP over HTTP

• NowSMS HTTP URL Parameter Reference

• Sending MMS Messages over HTTP

• 2-Way: Receiving SMS Messages over HTTP

• 2-Way: Receiving MMS Messages over HTTP

• Search the NowSMS Web Site for 2-Way SMS

• Search the NowSMS Web Site for 2-Way MMS

PHP Scripts for Sending SMS & MMS

• Sending SMS Text Messages with PHP

• Sending MMS Messages with PHP

• Sending OMA Client Provisioning Messages with PHP

• 2-Way: PHP Examples for Receiving SMS

• 2-Way: Receiving MMS with a PHP Script

• PHP Related Postings on the Technical Blog

• Search the NowSMS Web Site for PHP

Java Examples for Sending SMS & MMS

• Sending SMS Messages from Java

• Sending WAP Push Messages from Java

• Sending MMS Messages from Java

• Java Related Postings on the Technical Blog

• Search the NowSMS Web Site for Java

.NET Examples for Sending SMS & MMS

• Sending MMS Messages from VB .NET

• Sending MMS Messages from C# .NET

• .NET Related Postings on the Technical Blog

• Search the NowSMS Web Site for .NET

Command Line Interface for Sending SMS & MMS

Note: The Command Line Interface is particularly useful because you can easily spawn a command line script to interface with NowSMS.

• Sending SMS Messages

• Sending WAP Push and Binary SMS Messages

• Sending MMS Messages

• Sending OMA Client Provisioning Messages

• Command Line Interface Related Postings on the Technical Blog

• Search the NowSMS Web Site for Command Line Interface

The interface to support this is defined in the following article:

Mobile Number Portability (MNP) and the NowSMS MMSC

However, there is an additional issue that is not discussed in that article.

By default, the routing callback is only called for recipients that are not defined to the MMSC on the “MMSC Users” page.

In a typical operator MMSC configuration, new MMSC user accounts are automatically provisioned the first time a user sends an MMS message. This configuration is detailed in the article titled NowSMS MMSC Operator Considerations.

A problem scenario develops if a subscriber moves their number from this operator to another operator, after they have already been provisioned on the MMSC. The MMSC will see the user account and attempt to deliver the MMS message directly, without performing a routing lookup.

To address this scenario, an additional MMSC configuration parameter exists. Under the [MMSC] header or MMSC.INI, add the parameter ForceRoutingCallback=Yes. This setting will cause the routing lookup to always occur.

Prior to the 2009-06-30 release, to address this issue, we recommended instead using the setting DisableMMSDirectDelivery=Yes, a setting name which sounds contrary to the intended purpose. This other setting was originally added to NowSMS for a different purpose, but it does have the side effect of always forcing the routing callback.

We no longer recommend the use of DisableMMSDirectDelivery=Yes for this purpose, and instead recommend the ForceRoutingCallback=Yes setting. This is because DisableMMSDirectDelivery=Yes has an extra side effect of disabling the automatic version tracking of MMS clients. Because the MMS read receipt format was not introduced until OMA MMS v1.2, this can cause some clients to generate read receipts as regular MMS messages instead of using the read receipt format.

Mohit is using NowSMS Lite to send binary SMS messages to a Java application that his company is developing.

He noticed that when sending SMS binary messages longer than 140 bytes, the messages were received correctly by Nokia and SonyEricsson devices, however many Motorola devices received corrupted messages.

In GSM environments, a single SMS message can be no longer than 140 bytes.

When you send a text message, as long as the text only contains characters that are included in the GSM 7-bit character set , 160 7-bit characters are compressed into 140 8-bit bytes to produce the 160 character limit that we are so familiar with. (Note: 160 * 7 = 140 * 8 )

There’s more general discussion of SMS message size limits in the article at http://www.nowsms.com/long-sms-text-messages-and-the-160-character-limit.

But back to Mohit’s problem…

When sending a binary SMS message longer than 140 bytes, it has to be segmented into multiple SMS messages. A special header is added to each physical SMS message so that the receiving client knows that it is a multipart SMS message that must be reassembled by the client. These headers are known as segmentation or concatenation headers. 6 bytes (8-bits each) are required for these concatenation headers in each physical SMS message.

These headers are placed in the User Data Header (UDH) field of the message, but they do count against the overall size limit of the message.

As a result, a long binary SMS message will be divided into 134 byte segments. Or 153 characters per segment for standard text messages. Or 67 Unicode characters per segment for Unicode text messages.

Mohit observed that with various Motorola RAZR and SLVR models, the received message would lose one byte for each of these segments.

He had his applications on the phones send long binary SMS messages back in to NowSMS.

When his application on a Nokia or SonyEricsson device sent a long binary SMS message, it generated a User Data Header like this: 0B0504232923290003070301

0B is the length of the user data header.
05 indicates that source and destination port information is present in the message.
04 indicates the length of the source and destination port information.
2329 2329 indicates source and destination ports of 2329.
00 indicates that the message is segmented using an 8-bit reference number.
03 indicates the length of the segmentation headers.
07 is the 8-bit reference number for the segmented message.
03 is the number of segments in the overall message.
01 is the number of the current segment (i.e,. 1 of 3).

Long binary messages sent by the Motorola devices were different. A typical user data header looked like this: 0C080400460301050423292329

0C is the length of the user data header.
08 indicates that the message is segmented using a 16-bit reference number.
04 indicates the length of the segmentation headers.
0046 is the 16-bit reference number for the segmented message.
03 is the number of segments in the overall message.
01 is the number of the current segment (i.e,. 1 of 3).
05 indicates that source and destination port information is present in the message.
04 indicates the length of the source and destination port information.
2329 2329 indicates source and destination ports of 2329.

Whether the segmentation headers or port information headers was not significant. But what was significant was that the Motorola device was generating messages that used 16-bit reference numbers.

Mohit determined that when the Motorola device received a long binary message using an 8-bit reference number, it converted this to a 16-bit reference number. If the overall message length including UDH was 140 before this conversion, the conversion would cause the last byte of data in that segment to be lost.

The Motorola device didn’t seem to have any problems with standard long text messages being sent to the SMS client on the device, or with long binary WAP push messages. The bug seems to be in the part of the device code that routes messages to Java applications.

To make a long story short, this is an annoying bug. And if you’re sending messages to Java applications, you may encounter it.

To deal with this scenario, we added a configuration option to NowSMS and NowSMS Lite, which would cause NowSMS to use 16-bit reference numbers when generating concatenated multipart messages. By default, NowSMS uses 8-bit reference numbers, which allows the most characters to be fit in a single SMS.

When 16-bit reference numbers are used, message length per segment rules change. For long text messages, instead of 153 characters per segment, only 152 characters per segment can be achieved.

For Unicode messages, instead of 67 characters per segment, only 66 characters per segment can be achieved.

For binary messages, 133 bytes of binary data can be included per segment, instead of 134 bytes.

This 16-bit reference number support was added in the 2009.11.04 release of NowSMS. This support will be carried through to future releases. For now v2009.11.04 has been made available as a special release at http://www.nowsms.com/download/nowsms20091104.zip (standard version) and http://www.nowsms.com/download/lite20091104.zip (NowSMS Lite).

To enable 16-bit reference numbers, edit SMSGW.INI, and under the [SMSGW] section header, add ConcatRef16Bit=Yes.

Note that when this setting is applied, 16-bit reference numbers are only used when NowSMS performs the segmentation (message submitted either via HTTP, or via SMPP using a single message_payload submission) …

NowSMS does not resegment messages that have already been segmented by the submitting client.

For more about sending SMS messages to J2ME apps, see http://www.nowsms.com/sms-port-number.

This modem supports HSDPA up to 7.2 Mbps (although locating the appropriate firmware driver update seems to be a challenge, without it, it is limited to 3.6 Mbps). That is good for receiving MMS.

However, the modem does not support HSUPA, limiting it to 384 Kbps for uploads and sending MMS.

Although we have yet to test it, the Merlin X950D would likely be a better choice for MMS, as it claims to support HSUPA up to 2.1 Mbps (Note: the X950D requires a firmware update to enable HSUPA and there may be some difficulty locating the firmware update). SMS speeds should not be a difference between the two modems.

Drivers for this modem can be found on the Novatel Wireless web site at http://www.novatelwireless.com/index.php?option=com_content&view=article&id=220&Itemid=272. (If this direct link is broken, navigate from http://www.novatelwireless.com/support/.)

There are no special considerations for using the Novatel XU870 modem with NowSMS. However, it should be noted that this modem does NOT support delivery receipts.

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the Novatel Wireless Merlin XU870, please see the NowSMS Quick Start Guide at http://www.nowsms.com/doc/quick-start-guide.

Frequencies supported by the Novatel Merlin XU870:

• 3G/UMTS/HSDPA/HSUPA – 850Mhz/1900Mhz/2100Mhz (Good for most of the world, plus AT&T USA)
• EDGE/GPRS – 850Mhz/900Mhz/1800Mhz/1900Mhz (Global)
• HSDPA Max Performance: Download speed – 7.2 Mbps; Upload speed – 384 Kbps

The alternative approach is to write a simple VBScript macro instead.

Today was my first attempt at writing one … but I did manage to create a button in a spreadsheet, where when you click on the button, it reads data from the spreadsheet to send out an SMS.

Here’s what I did …

From the Developer menu in Excel, I added an Active X Command Button.

I then associated the following code with my command button:

Private Sub CommandButton1_Click()
Set objHTTP = CreateObject("MSXML2.ServerXMLHTTP")
URL = "http://192.168.0.222:8800/"
objHTTP.Open "POST", URL, False
objHTTP.send ("&PhoneNumber=" + Range("a9").Text + "&text=" + Range("a10").Text)
End Sub

In this particular case, I am extracting the phone number from cell A9, and the text to send from A10.

Once I exit design mode, I can click on the button, and it triggers this code, which makes the HTTP submission to NowSMS.

I’m using HTTP POST instead of GET to avoid some URL encoding issues.

It’s not as easy as using HYPERLINK, but hopefully you can adapt this to your scenario.

For alternative modems, please see our other reviews: http://www.nowsms.com/tag/gsm-modem

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the Alcatel One Touch X200 or X060, please see the NowSMS Quick Start Guide at http://www.nowsms.com/doc/quick-start-guide.

To point out one initial point of confusion when configuring NowSMS to work with the Alcatel One Touch modem, the modem driver installed for the modems is named “Modem Interface”. When adding the modem to NowSMS, you must select the modem named “Modem Interface” (which is a less than intuitive choice of name).
The primary problem when using the Alcatel One Touch X200 or X060 modem with NowSMS is that each time your PC is rebooted, the modem will be inaccessible to NowSMS until the Alcatel “HSPA USB Modem” software that ships with the modem is loaded. Until that software is run, the modem functions only as a USB disk drive, and there is no modem functionality.

If you want to run NowSMS automatically each time your PC is restarted, after installing NowSMS and verifying that it works with the Alcatel One Touch modem, reboot your PC. If NowSMS is unable to access the modem after a reboot, you will need to follow the following steps.

We have been unable to identify a solution for this problem, other than configuring the Alcatel “HSPA USB Modem” software application to run at startup.
For some reason, on Windows Vista and Windows Server 2008 systems, the Alcatel “HSPA USB Modem” software requires that it be run with administrative rights.
Therefore, the best way to configure this software to be started automatically when the PC reboots is to configure the Windows Task Scheduler to run it at startup.

The Windows Task Scheduler can be accessed via the “Schedule Tasks” option under “Administrative Tools” in the Windows Control Panel.

Select “Create Task” to create a new task to load the Alcatel “HSPA USB Modem” software at startup.

On the “General” page, give the task a name, such as “Alcatel HSPA USB Modem”, so that you can easily identify the task later. Under “Security Options”, select “Run whether user is logged on or not”, and “Run with highest priveleges”. The other settings on this page can be left at their defaults.

On the “Triggers” page, select “New”, and then specify to “Begin the Task” “At Startup”. Press “OK” to save the trigger.

On the “Actions” page, select “New”, and then specify the “Action” to be “Start a program”. In the “Program/Script” field, press “Browse” and locate “HSPA USB MODEM.EXE”, which is usually located in the “Program Files\HSPA USB MODEM” or “Program Files (x86)\HSPA USB MODEM” directory. Press “OK” to save the action.

On the “Conditions” page, clear any of the checked conditions, so that the program is always run at startup.

On the “Settings” page, check “Stop the task if it runs longer than”, and specify “5 minutes”. Also check “If the running task does not end when requested, force it to stop”.

Press “OK” to save this task. You will be prompted for your username and password.

Reboot your PC to confirm that NowSMS can now access the modem properly when the PC is restarted.

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the Alcatel One Touch X200 or X060, please see the NowSMS Quick Start Guide at http://www.nowsms.com/doc/quick-start-guide.

For alternative modems, please see our other reviews: http://www.nowsms.com/tag/gsm-modem

Frequencies supported by the Alcatel One Touch X200:

• 3G/UMTS/HSDPA/HSUPA – 850Mhz/1900Mhz/2100Mhz (Good for most of the world, plus AT&T USA)
• EDGE/GPRS – 850Mhz/900Mhz/1800Mhz/1900Mhz (Global)
• HSPA Max Performance: Download speed – 7.2 Mbps; Upload speed – 2 Mbps
• UMTS Max Performance: Download speed – 384 Kbps; Upload speed – 384 Kbps
• EDGE Max Performance: Download speed – 247.4 Kbps; Upload speed – 123.7 Kbps
• GPRS Max Performance: Download speed – 85.6 Kbps; Upload speed – 42.8 Kbps

The Alcatel One Touch X060 is similar to the X200, except that its HSDPA download speed peaks at 3.6 Mbps, and there is no HSUPA support, limiting HSPA upload support to 384 Kbps.

NowSMS Support Summary: Supports sending and receiving both SMS and MMS messages. Does not support “Direct to Modem” (“Default” mode is ok).

SMS Delivery Receipts are NOT supported.

The Alcatel One Touch X200 and X060 modems do not support an external antenna (uses internal antenna only).

End-users of T-Mobile USA have been asking us for feedback on modems that can work on T-Mobile’s 1700Mhz (AWS) US 3G network for sending and receiving SMS and MMS messages. (Other tri-band 3G modems typically only support 850Mhz/1900Mhz/2100Mhz.)

Unfortunately, the only GSM/3G modem that is currently offered by T-Mobile is the WebConnect USB stick (Huawei UMG181).
Like most mobile operators, T-Mobile assumes that you will be using the USB stick modem for internet access, not for sending and receiving SMS and MMS messages. As such, T-Mobile is blocking this device from accessing the “wap.voicestream.com” APN which is used for both WAP and MMS connectivity, and only allowing it to connect to the full internet access APNs with an appropriate data plan (with an inappropriate price).

Even if you take a SIM card from an existing mobile phone device with MMS support and put it into the USB stick, T-Mobile blocks the device from connecting to “wap.voicestream.com”, which is a requirement for sending or receiving MMS message.

As a result, it is not currently possible to use this modem to send or receive MMS messages on the T-Mobile USA network.

This modem appears to do a decent job of sending and receiving SMS messages. However, there is no real speed benefit compared to a decent EDGE modem like the Option ICON 322. And the EDGE modems have the benefit of also being able to support sending and receiving MMS messages.

For discussions of alternative GSM modems, see http://www.nowsms.com/tag/gsm-modem.

Of course, a true 3G modem is desirable for sending and receiving MMS messages, because MMS messages are more bandwidth intensive. We are investigating the Option ICON 452 as a possible alternative for T-Mobile USA users, as for 3G it supports 850Mhz/1700Mhz/1900Mhz/2100Mhz. Based upon experience with other Option ICON modems, we expect that to be an excellent modem, as long as T-Mobile does not block it from the MMS Access Point!

(Side note … in some other parts of the world, the GSM 900Mhz spectrum is starting to be re-allocated for use as 3G. The Option ICON 451 substitutes 900Mhz for 1700Mhz and looks like a good solution for parts of the world that are starting to see 900Mhz 3G coverage.)

This modem is readily available in many countries, as many mobile operators sell this modem as part of a mobile broadband package. (In the UK alone, we’ve seen this modem offered by 3, O2 and T-Mobile. Unlocked versions of this modem are avaialable from multiple web sites.)

Unfortunately, this modem has been one of the most difficult and frustrating modems for us to test. We tried two different E160 modems on at least four different computers, and were consistently frustrated with how unreliable this modem was. The most frequent problem was that after a couple of hours, the modem would become unresponsive, and NowSMS would be unable to communicate with the modem.

Because of this problem, we actually added a configuration option in the 2009.10.21 release of NowSMS to allow NowSMS to reboot the PC as a “last resort” effort to try to recover a non-responsive modem.

However, just when we were about to give up on the E160, we stumbled upon a solution to its reliability problems.

The E160 is bundled with some associated software called “Mobile Partner”. The modem lock-up problems do not seem to occur if the “Mobile Partner” software is active along with NowSMS.

There is an important consideration that the Mobile Partner software, by default, will try to process received SMS messages, and may remove these messages from the modem before NowSMS is able to process them. To correct this problem, it is very important that the Huawei Mobile Partner software be configured not to remove received SMS messages from the SIM card. From within Mobile Partner, select Tools/Options/Text Message and ensure that “New Message Save Mode” is set to “Save on SIM/USIM card or device”.

To address the reliability problems, it is also recommended that the Huawei Mobile Partner software be configured to automatically load on startup. From within Mobile Partner, select Tools/Options/General, and ensure that “Launch on Windows startup” and “Minimize window on startup” are checked.

Note that if your system is restarted, NowSMS runs as a service and will automatically be started without requiring a user to be logged in. However, the Mobile Partner software will not load until a user logs in to the PC. The fact that NowSMS is running without Mobile Partner may cause some reliability problems. One way to address this issue for a system that is to run unattended is to configure the PC to login to an account automatically when it is restarted. This can be done by going to the Windows Start Menu, selecting the “Run” option, and typing “control userpasswords2″. Uncheck the option that says “Users must enter a user name and password to use this computer, and then when you press OK, you will specify the user name and password that should be used for an automatic login.

The inconvenience of requiring the Mobile Partner software to be active when running NowSMS makes us hesitant to strongly recommend this modem. It works ok, and it does have the benefit of supporting SMS delivery receipts.

For alternative modems, please see our other reviews: http://www.nowsms.com/tag/gsm-modem

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the Huawei E160, please see the NowSMS Quick Start Guide athttp://www.nowsms.com/doc/quick-start-guide.

One additional note of interest for users of Huawei modems … updated firmware and drivers for Huawei modems can be found at the following page: http://www.huawei.com/mobileweb/en/doc/list.do?type=-1&id=5286

A software update for the E160G is available via the E160 link on that page, or http://www.huawei.com/mobileweb/en/doc/list.do?type=-1&id=5840

Note that if you update the modem firmware, this also updates the version of the Mobile Partner software accessible via the USB drive of the modem. After updating the firmware, you should remove Mobile Partner from your system, and then re-install the new version from the modem’s USB drive.

Frequencies supported by the Huawei E160:

• 3G/UMTS/HSDPA – 850Mhz/1900Mhz/2100Mhz (Good for most of the world, plus AT&T USA)
• EDGE/GPRS – 850Mhz/900Mhz/1800Mhz/1900Mhz (Global)
• HSDPA Max Performance: Download speed – 3.6 Mbps; Upload speed – 384 Kbps (no HSUPA support)
• EDGE/GPRS Max Performance: Not specified

NowSMS Support Summary: Supports sending and receiving both SMS and MMS messages. Does not supports “Direct to Modem” (“Default” mode can be used).
SMS Delivery Receipts are supported.

The Huawei E160 modem does have support for connecting an external antenna to enhance the strength of its internal antenna.

Another scenario is when it is desirable to have multiple applications share an existing SMPP connection. Multiple SMPP applications can connect to a NowSMS server and share an upstream SMPP connection.

We tend to get the most questions from end users who have an SMPP-based application that they want to interface with NowSMS where NowSMS is sending and receiving SMS messages via a GSM modem.

To answer the most frequently asked question, yes, the SMPP application can both send (MT, or mobile terminated) and receive (MO, or mobile originated) messages. This does require that the GSM modem being used supports sending and receiving SMS messages over the GSM modem interface (this is normally not a problem, except when using a Nokia phone as a modem … use a dedicated GSM modem device instead).

In this posting, we’ll give a quick overview of how to configure this type of setup.

Before you configure any SMPP related settings, start by setting up NowSMS to work with your GSM modem. The first two guides on the Quick Start Guide page of the NowSMS web site provide a good overview of this process.

Before continuing to the next step, confirm that you are able to successfully send SMS messages from the NowSMS web interface.

To enable an SMPP client to connect to the NowSMS server, there are two configuration steps that are required.

1.) The NowSMS SMPP server needs to be enabled. To enable the SMPP server, go to the “Web” tab of the NowSMS configuration. Check “Enable SMPP Server”, and specify a port on which NowSMS should listen for SMPP connections.

Any firewalls between your SMPP client and the NowSMS server will need to be configured to allow this connection.

2.) A user account needs to be defined on the NowSMS server. Your SMPP client will authenticate to NowSMS with this account information.

To define a user account, go to the “SMS Users” tab of the NowSMS configuration. Press “Add” to define a new user account.

Specify a “User Name” and “Password” to be used for the account.

Ensure that “Enable SMPP Login for this User” is enabled.

We also recommend specifying IP address restrictions to limit the IP addresses from which this account is allowed to connect. The “Restrict to IP Address(es)” field can contain a comma delimited list of allowed IP addresses. A wildcard character of “*” can also be used to specify an entire subnet, such as 192.168.0.*.

It is now possible to configure your SMPP client software to connect to NowSMS using the IP address or host name of the NowSMS server, and the port number that we configured in step 1.

Your SMPP client might refer to the “User Name” as a “system_id”, but it is just different terminology for the same parameter.

An additional point of confusing in SMPP environments are the TON and NPI values. The NPI value is not important for this type of configuration. The TON value should be set to “1″ if you are sending messages where the recipient phone number is in international format (includes a country code). If the recipient phone number is in local format, use a TON value of “0″.

So far we’ve only covered how an SMPP client can send messages through NowSMS.

It is also possible for an SMPP client to receive messages from NowSMS. There are two different ways to configure this:

A.) If you are using a GSM modem and want all messages received via that modem to be routed to your SMPP client, select “Properties” for the modem in the NowSMS SMSC list.  Select the name of your SMPP user account in the “Route SMS to local user” field. When this option is set, all SMS messages that NowSMS receives via this modem will be routed for delivery to your SMPP client.

B.) An alternative solution is available for more complex systems. One of the properties for the “SMS User” account is “Recipient address(es) to route to this user”. This property can contain a comma delimited list of phone numbers, which can include “?” (match 1 character) and “*” (match 0 or more characters) wildcards.

Whenever NowSMS routes a message that is addressed to a phone number that matches this list, it will route the message to the SMPP client instead of sending it via an outbound SMSC connection.

This property also applies to SMS messages that are received via an upstream SMSC connection. For example, if you have an SMSC connection that receives messages for multiple short codes, NowSMS can route the received messages to different SMPP clients depending on the short code number for which the message is received on.

That’s a quick overview of this functionality. If you have any questions, please visit us in the NowSMS Support Forum.

This article is a reference for SMPP error codes.

Error codes between 0×400 and 0x4FF are SMPP provider specific, and it is necessary to consult system documentation for the provider for more details.

For additional information, archived versions of the SMPP specification can be found at the following link: http://www.nowsms.com/smpp-3-4-protocol-specification-archive

And if you missed our recent announcements regarding NowSMS 2009, the NowSMS MMSC, and NowSMS Lite, you can learn more at http://www.nowsms.com/nowsms2009.

The most significant improvements in the NowWAP 2009 release are in the areas of scalability, performance and reporting.

For scalability and performance, NowWAP 2009 includes both 32-bit and 64-bit versions of the product.

Porting the application to a 64-bit platform increases the amount of memory available to NowWAP, allowing it to support larger numbers of concurrent users, and scale to thousands of transactions per second.

Performance analysis of NowWAP during this process also resulted in significant performance enhancements that could be applied to both 32-bit and 64-bit versions of the product. Our internal benchmark tests show significant speed improvements of 33% to 50% in core transaction processing speed.

Best of all, these performance enhancements required minimal changes to internal program logic, meaning that you’ll enjoy the same rock solid reliability that you’ve expected from NowWAP over the years.

Reporting has historically been one of the weak pieces of NowWAP. NowWAP 2009 introduces new activity reports that will help in managing network capacity.

Additional details on these reports can be found in the PDF version of the NowWAP 2009 Manual.