A VB.NET example for sending MMS messages via NowSMS has been posted at the following link: http://www.nowsms.com/download/sendmms.vb.txt

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.

A .NET C# example for sending MMS messages via NowSMS has been posted at the following link: http://www.nowsms.com/download/sendmms.c#.txt

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.

It has come to our attention that there is a bug in the MMS client of the Nokia N9 which can prevent this phone from being able to receive MMS messages from a NowSMS MMSC.

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.

It has come to our attention that a bug exists in the NowSMS SMPP Server implementation for versions dated between 2011.07.xx and 2012.01.xx inclusive.

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.

NowSMS has long supported external account provisioning via HTTP as described in the article at http://www.nowsms.com/provisioning-sms-and-mmsc-user-accounts-via-http.

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=####

Accounting callbacks provide an interface between the NowSMS SMS Gateway and external billing and charging systems.  They can also be used to control message routing, providing a way for a  user application to control which SMSC connections are used for sending particular messages.

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.

This article will explain how NowSMS handles retry situations when processing inbound SMS messages via a 2-way command, and there is a connectivity or other problem processing the 2-way command, particularly with regard to HTTP based 2-way SMS message processing commands.

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.

Our technical bulletins describe advanced technical features of the Now SMS & MMS Gateway and clarify advanced configuration options.

Follow this link to browse all technical bulletins, or select a topic from the list below.

It is also possible to subscribe to receive new technical bulletins automatically via e-mail.

We’d like to draw some attention to an issue that was reported (and quickly diagnosed) on our discussion forum last month.

A customer reported that they were no longer able to process received MMS messages using a GSM modem on the Orange  network in the UK.

There are a variety of potential causes, such as a SIM not being enabled for MMS support, or incorrectly provisioned Operator MMS settings.  However, this case was unusual.

Generally when there is a problem receiving MMS messages via a modem, the first thing we check is whether or not the modem can be used to send MMS messages.  Assuming that is OK, we look to see if NowSMS is reporting receiving any SMS messages when an MMS is expected.  As described in the How MMS Works article, the initial trigger for MMS message delivery is a specially formatted SMS message known as an MMS Notification.

The MMS Notification message was being received via SMS, and looking at the SMSDEBUG.LOG, it was determined that NowSMS was attempting to retrieve the MMS message using valid settings, but the operator MMSC was returning an error code 412 (Precondition Failed).

Needless to say, a web search for more information on HTTP error 412 Precondition Failed does not offer any good suggestions for what the problem might be.

However, in the discussion thread, Des correctly diagnosed that the MMSC was expecting something in the request that was not being provided, and suggested that the MMSC might be complaining that no user agent profile information is present in the request to retrieve the MMS message.

The solution to the problem was to locate and manually edit the MMSC.INI configuration file, adding the following settings under the [MMSC] section header:

HeaderUserAgent=iPhoneOS/4.2.1 (8C148) 
HeaderProfile=http://www.apple.com/mms/uaprof.rdf

For additional details, please refer to the original discussion thread:  Unable to retrieve mms using nowsms and orange.

This is a preliminary document outlining how MMS charging is to be implemented using Diameter and MM9 in the NowSMS MMSC. It also describes a test program that is used to validate proper Diameter configuration parameters and charging behaviour.

The MMSC implements Diameter Credit Control for charging based upon the following specifications:

• [DIAMBASE] – RFC 3588 – Diameter Base Protocol
• [DIAMCCA] – RFC 4006 – Diameter Credit Control Application
• [3GPPDIAM] – 3GPP TS 32.299 – 3GPP Diameter Charging Applications

[3GPPDIAM] defines a standard format for implementing MMS charging over Diameter, known as MM9 in the MMS protocol specifications. While the MMSC preference is to use MM9, it is also possible to configure the MMSC to use generic charging primitives defined in [DIAMCCA] in order to facilitate interoperability with a wider base of charging systems.

The MMSC will generate two different Diameter requests, which are described in detail in this document.

Capabilities-Exchange-Request is used to initiate the connection and identify that the connection is to be used for Diameter Credit-Control. In response, the MMSC expects to receive a Capabilities-Exchange-Answer that contains a Result-Code of 2001 to indicate success.

Credit-Control-Request is used to provide details for an MMS charging operation. In response, the MMSC expects to receive a Capabilities-Exchange-Answer that contains a Result-Code of 2001 to indicate success. The MMSC will reject the MMS submission if any other Result-Code is received.

MM9Test Program

The MM9Test program is used to test and validate proper configuration parameters and charging behaviour by initiating a Diameter connection and sending a charging request for a single MMS message.  The latest version of this program can be downloaded at http://www.nowsms.com/download/mm9test.zip.

The MM9Test program generates the two Diameter requests detailed in this document: Capabilities-Exchange-Request and Credit-Control-Request.

MM9TEST.EXE is a command line program. When run, MM9TEST.EXE will prompt for the following Diameter related configuration parameters:

(Remote) Diameter Server Host Name or IP Address – The DNS host name or IP address of the Diameter Server that will receive the connection.

(Remote) Diameter Server Port Number – The port number for the Diameter server that will receive the connection.

(Remote) Diameter Destination-Host – The Destination-Host parameter to be specified in the Diameter requests.

(Remote) Diameter Destination-Realm – The Destination-Realm parameter to be specified in the Diameter requests.

(Local/Origin) Diameter Host-IP-Address – The IP address of the local host. This is a required property for the Capabilities-Exchange-Requst.

(Local) Diameter Origin-Host – The Origin-Host parameter to be specified in the Diameter requests.

(Local) Diameter Origin-Realm – The Origin-Realm parameter to be specified in the Diameter requests.

Service-Context-Id (optional) – See Credit-Control-Request for parameter definition. Default is 32270@3gpp.org as defined in [3GPPDIAM] to indicate MMS charging.

Service-Identifier (optional, leave black for standard MM9) – See Credit-Control-Request for parameter definition.

Requested-Service-Unit CC-Service-Specific-Units (optional, leave black for standard MM9) – See Credit-Control-Request for parameter definition. If this parameter is used, leave CC-Money and Currency-Code parameters blank.

Requested-Service-Unit CC-Money (optional, use decimal format 1.23) – See Credit-Control-Request for parameter definition. If this parameter is used, leave CC-Service-Specific-Units blank and specify a value for Currency-Code parameter.

Requested-Service-Unit Currency-Code (optional, use ISO 4217 currency code) – See Credit-Control-Request for parameter definition. If this parameter is used, leave CC-Service-Specific-Units blank and specify a value for CC-Money parameter.

MMS Sender Phone Number – MSISDN to be charged for sending MMS message. Used to build Subscription-Id and Originator-Address in Credit-Control-Request.

MMS Recipient Phone Number – MSISDN receiving MMS message. Used to build Recipient-Address in Credit-Control-Request.

3GPP-SGSN-MCC-MNC (optional) – If available to the MMSC, the SGSN MCC-MNC value can be used to detect roaming subscribers. If left blank, or not available, this parameter is not included.

SGSN-ADDRESS (optional) – If available to the MMSC, the SGSN-ADDRESS value can be used to detect roaming subscribers. If left blank, or not available, this parameter is not included.

If successful, the last line of output from the test program will read Diameter Result Code 2001.

Raw Diameter packet information will be logged to MM9TEST.LOG. However, for easier troubleshooting, it is recommended that Wireshark be used to capture and log connection details. Wireshark will decode Diameter protocol information to more clearly report any protocol errors returned, as protocol errors typically relate to not having used the parameter values expected by the Diameter server.

NowSMS is frequently used to provide SMS message routing connectivity between multiple SMSCs using the SMPP protocol. The purpose of this document is to clarify issues that are frequently encountered in SMS hubbing configurations.

In SMS hubbing configurations, NowSMS is connected to one or more service providers using the SMPP protocol. Service providers route selected SMS messages to NowSMS over an SMPP connection, and NowSMS is then used to route the SMS message to a different service provider over another SMPP connection.

The concept is simple, but the implementation can be challenging, due in part to issues of routing and mobile number portability (MNP), and due to the architecture of the SMPP protocol.

Message routing in NowSMS is controlled by either prefix routing or dynamic HTTP-based routing callbacks. Message routing is discussed in a separate article titled Dynamic SMS Message Routing with HTTP Callbacks.

When configuring an SMPP connection for hubbing, an important consideration is which party initiates the connection. This is important because the SMPP protocol assumes a client-server relationship. The party that initiates a connection is the client, or ESME. The party that accepts the connection is considered the server, or SMSC.

SMPP connections where NowSMS initiates the connection (NowSMS = ESME) are defined in the “SMSC” list.

SMPP connections where the other party initiates the connection (NowSMS = SMSC) are defined in the “SMS Users” list.

An ESME transmits SMS messages to an SMSC using an SMPP data packet called submit_sm.

An SMSC transmits SMS messages to an ESME using an SMPP data packet called deliver_sm.

Figure 1 illustrates the typical message flow in a simple ESME to SMSC configuration.

A hub connection is not a client-server relationship, instead logically it is a peer-to-peer connection. However, the SMPP protocol rules must still be followed and submit_sm or deliver_sm must be used depending on the direction of the connection.

Differences between submit_sm and deliver_sm create problems for message ID tracking, particularly with regard to delivery reports. This is because SMPP message IDs are not global, but exist only on a hop-by-hop basis.

When an ESME submits an SMS message to an SMSC using submit_sm, the SMSC assigns a new message ID when accepting the message, and returns the newly assigned message ID in the submit_sm response. The SMSC has no knowledge of any previously assigned message ID. From this point forward, any delivery reports that might be generated will reference the message by this new message ID. Any upstream SMSC will eventually route a deliver_sm packet containing this delivery report back to the ESME, and the ESME will need to have remembered/tracked the message ID assignment from the submit_sm response in order to know the message to which it refers.

In an SMS hubbing scenario, if an SMSC has a message to route to an ESME, it uses deliver_sm to transfer the message. The deliver_sm packet contains no message ID information, so the receiving ESME has no knowledge of message IDs that were previously assigned to the message. To further process the message, the ESME needs to assign a new message ID to the message. Unlike the submit_sm response, the deliver_sm response cannot report this newly assigned message ID back to the other side of the connection. Any delivery reports generated will reference this new message ID, however this message ID is not known to the original SMSC, and it cannot be tracked back to the original message to which it refers.

Figures 2 and 3 highlight the problems encountered when the SMS hub functions solely in the role of SMSC or ESME.

In a typical SMS aggregator scenario, an upstream SMSC functions as both an SMSC and ESME when routing messages, and is able to successfully route messages from ESME to the upstream SMSC and delivery reports from the upstream SMSC back to the ESME, as shown in Figure 4.

However, this scenario still expects a client-server relationship.

There are two ways to overcome these limitations for true peer-to-peer SMS hubbing.

1.) Each side of a hub connection connect to the other party as both ESME and SMSC. Regular SMS messages are always routed from ESME to SMSC, and delivery reports are always routed from SMSC to ESME. From a NowSMS perspective, the NowSMS initiated connection is defined in the “SMSC” list, and the other party initiated connection is defined in the “SMS Users” list.

This scenario is illustrated in Figure 5.

2.) Instead of using submit_sm and deliver_sm, the SMPP protocol defines an alternative packet format called data_sm. This data_sm packet can be used regardless of the direction of the connection, and when used in place of deliver_sm, can return message ID information. NowSMS 2013 provides configuration settings to enable the use of data_sm for either an ESME or SMSC connection.

This scenario is illustrated in Figure 6.

NowSMS always performs automatic SMPP message tracking, translation and routing for delivery reports. However, the expected flow of delivery reports is from SMSC to ESME. In order for NowSMS to be able to properly understand and route a delivery report received from an ESME (i.e., “SMS Users” connection), NowSMS must be configured to “Use data_sm PDU” when communicating with this account.

Similarly, If the connection is defined in the NowSMS “SMSC” list, it is also normal to enable the setting “Re-Route Received Messages for Outbound Delivery” under the Advanced Settings for the SMPP connection. Normally, messages received from an SMSC connection are routed to a 2-way command for processing. This setting changes the behaviour so that messages received from this SMSC connection are queued for outbound delivery.

Important Note: Do not confuse SMS hubbing and ESME/SMSC roles with the concept of whether or not to use a transceiver connection. The concept of one connection vs. two connections is similar, but different.

When an ESME initiates a connection to an SMSC, it specifies what type of connection it wants. Connection types are transmitter (send only), receiver (receive only) and transceiver (send and receive). When NowSMS connects to an SMSC, the default behaviour is to use separate transmitter and receiver connections. Transceiver mode can be enabled to use a single connection for both sending and receiving messages.

With a transceiver connection, the initiating side of the connection is still considered to be in the role of ESME. Therefore the hubbing considerations of which party is ESME and which is SMSC still apply.

Some of our customers have been frustrated by an AT&T policy that blocks the sending of mobile originated WAP Push messages.  This prevents WAP Push messages from being sent over a GSM modem.  This blocking affects all messages that are sent via WAP Push, not just service indication messages, but also blocking OMA OTA settings and MMS notifications.

A NowSMS customer discovered a potential work-around by changing the TP-Protocol-ID (PID) value in the SMS message.

NowSMS has been updated to use configurable DCS and PID values when sending all types of WAP Push messages (including OMA OTA config). Previous versions of NowSMS only allowed the DCS value to be configured for WAP Push. These settings are available in NowSMS version 2013.04.01 and later.  (An update that supports these configurable values is available at http://www.nowsms.com/download/nowsms20130401.zip.)

By default, NowSMS uses a DCS value of F5 (binary, message class=2, ME specific) and a PID value of 0, which would be considered normal values.

It has been previously noticed that some providers will not accept DCS=F5 over a GSM modem connection and require a value of DCS=4 (generic binary).

One of our customers noticed in testing that by changing the PID value to 1 allowed WAP Push messages to be sent over a modem on the AT&T network. Technically speaking, PID=1 is an odd setting as it technically means the message originated as a Telex. We are suggesting that customers instead try using PID=41, which is a more normal setting, meaning replace short message type 1.

To set DCS or PID overrides for WAP Push messages generated by NowSMS, it is necessary to manually edit SMSGW.INI and under the [SMSGW] header, add:

PushDCS=F5
PushPID=41

(or try PushPID=1 if 41 does not work)

Please note that it is possible that AT&T may also decide to prevent this work-around. And note that cross operator WAP Push continues to be unavailable for messages submitted via a GSM modem in the USA.

Additional discussion of this issue can be found on our discussion forum at http://www.nowsms.com/discus/messages/1/71586.html.

The Now SMS & MMS Gateway can use a GSM/GPRS or 3G/UMTS/WCDMA modem to send and receive MMS messages via an operator MMSC. In this type of configuration, there is no special setup requirement required by the mobile operator. The Now SMS & MMS Gateway sends and receives MMS messages using the same protocol that is used by the MMS client in a mobile phone, so it simply requires that the SIM card in your mobile phone be provisioned by your mobile operator for MMS support.

However, in order to make this work, you need to configure NowSMS with the appropriate MMS settings for the mobile operator whose SIM card is being used in the GSM modem.

To simplify this process, we include a list of settings for many mobile operators that can be selected from a drop down list within the NowSMS configuration.

However, it has been awhile since we last updated that list, so you might find that your mobile operator is not included in the list.

This post contains an updated list of mobile operator MMSC settings. You can also download this list in a NowSMS compatible format from http://www.nowsms.com/download/mmsop.ini. Save the “mmsop.ini” file to your NowSMS program directory (usually \Program Files\NowSMS or \Program Files (x86)\NowSMS, and NowSMS will automatically use the updated list.

In the following table, note that most versions of NowSMS refers to the “MMS Proxy” setting as the “WAP Gateway Address”.  If this address includes a port number (address:port), versions of NowSMS prior to 2013 releases require the address to be prefixed by http:// (for example http://10.1.2.3:8080).

For more information on configuring NowSMS to send MMS messages via a modem, please see: Using a GPRS Modem.

Emoticons have long been part of text messaging (and before that e-mail), ranging from simple smileys such as : ) and : – ) to flowers @>–>—.  Traditionally, emoticons have been pictorial representation of a feeling or expression, with that picture being constructed by combining punctuation characters and other standard text characters.  Some messaging clients automatically replace common emoticons such as smileys with a graphic image, such as .

In Japan, emoji characters were added to mobile phones to provide users with access to graphic pictograms that were richer in presentation than this character based representation.

Due to interoperability considerations, emoji characters were incorporated into the Unicode 6.0 standard in 2010.

While Apple had supported emoji characters in prior versions of iOS, Apple began supporting these characters using Unicode encoding in iOS5.  Emoji characters are also widely supported with Unicode encoding in Windows Phone.  A smaller number of emoji characters are supported by current Android releases (as of version 4.3).

To include these emoticon/emoji characters in a text message, the text message must be sent over the air using Unicode format, more specifically UTF-16.

For this reason, it is appropriate to recall the message formats and size limitations for SMS.

GSM text messages are limited in size to 140 8-bit bytes of message data per message.  To facilitate longer messages, headers can be included in the SMS message data to tell the receiving client to combine multiple segmented messages and display them as a single long message.  This segmentation header (included in the user data header of the message data) requires 6 bytes, meaning that each segment of a long message can include no more than 134 bytes of message data (134 + 6 = 140).

In practice, there are three types of encoding that can be used for a text message.

Binary – Used for system messages, such as voice mail notification, WAP Push, MMS Notification, SIM update, etc.

Text – Message can only contain characters included in the GSM 7-bit character set (see tables and info in Long SMS Text Messages and the 160 Character Limit). This restricted character set which contains English characters, plus a few symbols, and some international characters for Western Europe and Greece (Greek capital letters are included). 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 ) For long messages, up to 153 7-bit characters can be present in each message segment.

Unicode – For text messages that include any characters outside of the GSM 7-bit character set, UTF-16 Unicode encoding must be used for the entire message.  This encoding uses 16 bits (2 bytes) for each character (with some characters, such as many emoticons requiring 32 bits, or 4 bytes, per character).  Each and every character in a Unicode format message must be encoded using at least 16 bits, even if the character is part of the GSM 7-bit character set.  This results in a limit of 70 16-bit characters in a single Unicode format message, or up to 67 characters per segment in a long message.

(Side note:  For some languages, especially Turkish, shift tables can be used as an alternative to Unicode format.  For more detail, see Shift Tables – National Language SMS in 160 characters without Unicode.)

For more review of these issues, please see Long SMS Text Messages and the 160 Character Limit.

NowSMS automatically decides whether to use Unicode format depending on whether or not characters present in the message are all part of the GSM character set.

Emoticon and emoji symbols are outside of the GSM character set, requiring that any SMS text messages using these characters be encoded in Unicode format.

As an example, the smiley emoticon is Unicode character 0x16F03.

One thing that you will immediately notice by its character code is that this character code is larger than can be represented in 16 bits.

As the Unicode standard has grown, it has been determined that not all universal characters can be accommodated within the 65,536 possible codes available in a 16-bit alphabet.

Characters that can be encoded in 16 bits are known as the UCS-2 alphabet.  The full Unicode character set, which includes characters 0×10000 and above is known as the UCS-4 alphabet.

Unicode SMS format was originally defined as using UCS-2 encoding, but standards updates have changed this to use UTF-16 encoding instead.  Characters below 0×10000, which are part of the UCS-2 range, are encoded in UTF-16 as their standard 16-bit character value.  Characters 0×10000 and above (UCS-4) are encoded in UTF-16 with two 16-bit characters.  (Portions of the UCS-2 character space were reserved to prevent conflicts.)

Our friend the smiley emoticon is 0x00016F03 in UCS-4 (or UTF-32) encoding.  In UTF-16 encoding, it is encoded as two 16-bit characters, 0xD83D followed by 0xDE0x.

But wait … it gets a little more complicated.

When working with the HTTP protocol, Unicode characters are more typically encoded using UTF-8 encoding.  This is the default character set used by NowSMS HTTP interfaces.

In UTF-8 encoding, (0x16F03) is encoded as four 8-bit characters 0xF0 0x9F 0×98 0×83.

NowSMS version 2013.08.30 or higher is required to support emoticon characters outside of the 16-bit UCS2 range.

Beginning with this version of NowSMS, we have added an emoticon and emoji character chart to make it easier to insert these characters into a text message. Click on the smiley below the text box in the “Send Text Messsage” web form to access this character chart. Click on any character to insert the character into the message text. Click on any section header (i.e., the text that says “Emoticons”) to toggle on or off a chart that displays the UTF-32, UTF-16 and UTF-8 characters for characters in that row … simply replace “x” with the hex digit from the column header.

We have also included a version of this chart at the bottom of this post.

Note that not all web browsers support all defined characters, and not all phones support all defined characters. Of particular note, current versions of Google Chrome do not support emoji without an extension (Chromoji). Current versions of that extension do not support emoji in embedded frames. A non-embedded version of this chart is available at http://www.nowsms.com/emoticons.htm.

National flags supported by current versions of iOS are also included in this chart without character codes, as their encoding is more complex, requiring two UTF-32 characters or four UTF-16 characters to represent a flag. The two UTF-32 characters are regional indicator symbols based upon ISO 3166-1 alpha-2 two-letter country codes. The regional indicator symbol range starts with A=0x1F1E6 and continues thru Z=0x1F1FF. As an example, for the UK flag, GB is the ISO 3166-1 alpha-2 country code. G=0x1F1EC and B=0x1F1E7. Conversions to UTF-16 and/or UTF-8 are left as an exercise for the reader.

Note:  A non-embedded version of this chart is available at http://www.nowsms.com/emoticons.htm.

Burst mode is a licensing enhancement to help customers better handle bursts of SMS and/or MMS messaging activity. Instead of just tracking message throughput per minute or second, NowSMS also keeps track of activity over the past two hours, and allows unused throughput capacity during that period to be applied as a performance burst.

Performance burst activity will provide up to double the license throughput for up to 60 minutes.

For example, consider a 10 message per second license which has been completely idle with no messaging traffic for at least 60 minutes. A large bulk submission occurs and burst mode will be automatically activated to operate at 20 messages per second for 60 minutes. After 60 minutes, burst mode deactivates and the speed reverts to 10 messages per second, until there is again a period of time where messaging traffic is below the licensed limit.

That is an extreme example. In more typical usage scenarios, burst mode helps better manage the peaks and valleys of message traffic by applying the license speed cap on a rolling two hour period, allowing unused capacity from the previous 120 minutes to be reclaimed with burst mode.

Burst mode licensing support is enabled in NowSMS versions 2013.08.30 and later.

The SMPP protocol defines support for optional parameters, known as TLV parameters. Some TLV parameters are defined in the core specification, and NowSMS may use them depending on configuration settings. These TLV parameters include message_payload, source_port, dest_port, sar_msg_ref_num, sar_total_segments, sar_segment_seqnum, payload_type, message_state and receipted_message_id. (There are also advanced configuration settings to generate values for user_message_reference and callback_num, which were required by specific customer implementations.)

SMS service providers are free to define their own TLV parameters, which sometimes may be required when interfacing with a mobile operator.  These TLV parameters might include operator information for inbound messages, pricing information for premium rate SMS, or other security and fraud prevention parameters required by that service provider.

NowSMS provides flexibility to configure support for custom TLV parameters as needed.  TLV parameters must be manually defined to NowSMS before they can be used.

TLV stands for Tag, Length and Value, which is the basic format of these parameters.

Tag is a numeric value, usually expressed as a hexadecimal value, that the provider defines for the parameter.   These values are usually 0×1400 or higher for service provider specific parameters.  While the parameter is logically thought of as a Name=Value pair, this number is used in the SMPP request instead of a parameter name.

Length and Value are used to encode the parameter value in the SMPP request.

Interpreting a TLV parameter can be tricky because the format of the value depends on how the provider defines the parameter.  Values might be encoded as a string value, a numeric value, or binary data.  For string values, it can sometimes be more complicated because the SMPP protocol defines two types of strings, a C format string that is null terminated (as is common for strings when working with the C programming language) and another that does not include the null terminator.  Some provider parameter implementations can become confused over this minor difference.

Generally, to define a TLV parameter to NowSMS, you need to know its Tag number (hexadecimal) and format of the value data.

When this is known, manually edit SMSGW.INI and create or modify an [SMPPOptions] section to define the parameter details.

The basic format is:

[SMPPOptions]
parametername=####,Type,Len

parametername is a descriptive name to be associated with the parameter.  NowSMS will use this name when converting the parameter to and from HTTP formats.

#### is the parameter tag number as a hexadecimal number. Do not include any prefix to indicate hex format…for example, 0×1400 is  just 1400 for this parameter setting.

Type specifies the parameter type: Integer, String, CString or HexString.

Len is optional, but is usually required for Integer values to specify a 1, 2 or 4 byte value, as defined by the provider.  (4 byte integer parameters require NowSMS 2013.08.30 or later. Earlier versions of NowSMS can only support 4 byte integers using the HexString format.)

CString is a text string that is null terminated (e.g., final 00 byte at the end), String is a text string that is not null-terminated.

HexString treats the value as binary data and converts it to a string of hex characters for HTTP (and back to binary for SMPP).

Len can be used for String or HexString to force a length (truncate value at length or pad with nulls).  In most cases, Len is omitted from the parameter definition for String, CString and HexString format parameters, unless the provider requires the parameter to have a specific length.  (NowSMS will generate the L for the TLV based on actual value string length.)

Example

This is all easier to explain with an example.

For the purpose of this example, we will assume that our provider has defined a TLV parameter called request_id.  It is a text string and has a tag number of 0×1555.

We define the following in SMSGW.INI:

[SMPPOptions]
request_id=1555,String

If NowSMS receives an SMS from the provider via SMPP which includes this parameter, accounting callbacks and 2-way commands will automatically have this parameter added to the HTTP request as &SMPPOption_request_id=xxxxx (xxxxx is the value of the parameter that was parsed from the message).

When submitting a message to NowSMS via HTTP, this same &SMPPOption_request_id=xxxxx can be used to specify that the TLV parameter should be included when submitting the message to the SMPP provider.

To Always Include Parameter With A Default Value

If you want to automatically include a TLV parameter in every message without requiring it to be explicitly set for each message submission, it is possible to configure NowSMS to use a default value for this parameter when submitting messages to your SMPP connection.

To define a default value for this parameter, manually edit the SMSGW.INI, and in the section header for an SMPP connection (e.g., [SMPP - ip.address:port]), add a “DefaultSMPPOptions=” setting, where the value of this setting can contain any of the “SMPPOptions” settings. For example:

DefaultSMPPOptions=request_id=myrequest

(If you have multiple SMPPOptions parameters defined that need to be set as default, separate them with a “;”. For example: DefaultSMPPOptions=request_id=myrequest;otherparm=othervalue)

To Include TLV Parameter In 2-Way SMS Reply

Another common requirement for some TLV parameter is that when generating an automatic reply to a message, the value of the TLV parameter in the received message must be copied over to the new reply message. If you are using 2-way SMS to send replies to incoming messages (“Command returns response text” is checked for the 2-way command), add 2WayReplyCopySMPPOptions=requestid to the [SMSGW] section of SMSGW.INI. This setting tells NowSMS that if it is processing a 2-way command reply, it should automatically copy the request_id TLV parameter from the source message to the reply.

More Examples

Additional examples can be found at the following links:

mBlox TLV Parameters: http://www.nowsms.com/mblox-and-nowsms-premium-rate-sms-and-oppc

For a more recent mBlox parameter, also see: http://www.nowsms.com/discus/messages/1/71879.html

Copying a TLV parameter for a 2-way reply where the actual sender address is hidden:  http://www.nowsms.com/discus/messages/1/71840.html

Provider specific parameters: http://www.nowsms.com/premium-rate-sms-oppc-with-verisign-and-nowsms

More provider specific parameters: http://www.nowsms.com/discus/messages/1/70296.html

Using TLV for advanced message routing: http://www.nowsms.com/smpp-tlv-parameters-for-advanced-message-routing

TLV for 2-way response via USSD: http://www.nowsms.com/discus/messages/1/41585.html

SMPP TLV parameter for PRICEPOINT: http://www.nowsms.com/discus/messages/1/71897.html

An updated release of NowSMS & NowMMS is now available for general release.

Existing customers who have a current software update license can use the trial download to update their existing installation.  Please see the Serial # page of the NowSMS configuration program to determine software update eligibility.

There are numerous enhancements in this release, some of which have been made available and tested in interim releases over the past year.

This document will highlight some of the more significant changes in this release.  For additional detail, please refer to our changes log for NowSMS.

Burst Mode Licensing

Burst mode is a licensing enhancement to help customers better handle bursts of SMS and/or MMS messaging activity. Instead of just tracking message throughput per minute or second, NowSMS also keeps track of activity over the past two hours, and allows unused throughput capacity during that period to be applied as a performance burst. Performance burst activity will provide up to double the license throughput for up to 60 minutes.

For additional detail, see Burst Mode Licensing Support.

MMSC Diameter MM9 Implementation

The Now MMSC supports the use of MM9 or Diameter based charging for MMS messages. This MM9/Diameter implementation is highly configurable, with configuration options that allow the Diameter requests to be tuned to meet the requirements of different operator charging systems.

For Extensive additional information, see Now MMSC Diamteter MM9 Implementation.

SMS Hubbing Considerations

NowSMS is frequently used to provide SMS message routing connectivity between multiple SMSCs using the SMPP protocol.

In SMS hubbing configurations, NowSMS is connected to one or more service providers using the SMPP protocol. Service providers route selected SMS messages to NowSMS over an SMPP connection, and NowSMS is then used to route the SMS message to a different service provider over another SMPP connection.

This update includes several enhancements to provide flexibility for SMS hubbing configurations.

Configuration options allow inbound deliver messages to be rerouted to outbound submit format for delivery to another SMSC connection. Delivery report message ID tracking has been enhanced to support these rerouted messages to the extent that is technically possible with extensive configurable support for the SMPP data_sm message format.

SMS hubbing considerations are discussed in the article SMS Hubbing Considerations, and we welcome further discussion and clarification in our Support Forum.

SMPP Optional TLV Parameter Support

The SMPP protocol defines support for optional parameters, known as TLV parameters. SMS service providers are free to define their own TLV parameters, which sometimes may be required when interfacing with a mobile operator. These TLV parameters might include operator information for inbound messages, pricing information for premium rate SMS, or other security and fraud prevention parameters required by that service provider.

NowSMS has long supported configurable TLV parameters.  This version adds improved support for long integer format parameters.

Learn more about TLV parameter settings in the article SMPP Optional TLV Parameters.

MM7 and MM4 Performance

Overall speed and performance has been greatly improved for message processing over MM7 and MM4 protocol, and for conversions between different MMS message formats including MM1, MM4 and MM7.

MM4 forward.RES acknowledgment performance has also been greatly enhanced to remove potential performance bottlenecks with operator interconnects.

Outbound connections can now be configured to specify the number of concurrent connections allowed and the maximum number of recipients per message instance. (For proper delivery report handling across some MM4 interconnects, it is necessary to break multiple recipient messages into separate message instances for each recipient.)

MMSC Group Messaging Support Across MM4 & MM7 Interconnects

MMS is about more than just sending pictures and videos.  The biggest growth driver in MMS messaging volume over the past year has been increased usage of MMS to deliver group text messages.  The benefit of MMS for group text messages is that a complete list of recipients can be maintained, allowing recipients to reply all, and hence driving a large increase in messaging traffic.

Most current Android, iPhone and Windows Phone devices now default to using MMS for group messaging.

When NowSMS is functioning as an MMSC, previous versions would not always maintain the complete recipient headers when messages were transferred between operators over an MM4 or MM7 interconnect.

ICAP Protocol Support for Additional MMSC Deployment Flexibility

The Now MMSC can now support subscriber identification/authentication for configurations that do not use a WAP gateway or proxy server, or for configurations where some subscribers use a proxy/gateway and other subscribers do not.

The MMSC can issue ICAP client requests to request subscriber identification from an ICAP server that can provide HTTP Header Enrichment.

The latest version of NowWAP has been enhanced to provide HTTP Header Enrichment via an ICAP server interface for the type of configuration described.  This ICAP server interface can also be used for configurations that are using a Squid based proxy server, as Squid can easily be configured to selectively request HTTP Header Enrichment from NowWAP.

For more information, start a discussion on our support forum, or contact us via e-mail.

Emoticons and Emoji in SMS Messages

Emoticons have long been part of text messaging (and before that e-mail), ranging from simple smileys such as : – ) to flowers @>->-. Traditionally, emoticons have been pictorial representation of a feeling or expression, with that picture being constructed by combining punctuation characters and other standard text characters. In Japan, emoji characters were added to mobile phones to provide users with access to graphic pictograms that were richer in presentation than this character based representation.

Some messaging clients automatically replace common emoticons such as smileys with a graphic image, such as .

Due to interoperability considerations, emoji characters were incorporated into the Unicode 6.0 standard. NowSMS now supports 32-bit Unicode characters in SMS messages, whereas previous versions were limited to 16-bit Unicode support.

More information on how these characters are encoded in the modern world of SMS can be found in the article Emoticons and Emoji in SMS Messages.

MMS to SMS Conversion for Multimedia Message Delivery

Sometimes the most cost effective way to deliver MMS message content is to convert the MMS content to a web-link that is sent via SMS.

NowSMS has long supported this capability, but we’ve greatly improved the message templates and formatting compared to previous releases.

Easier E-Mail to/from SMS and/or MMS

Additional flexibility has been added for bi-directional e-mail to SMS and/or MMS configurations. Instead of requiring NowSMS to be setup as a separate SMTP mail server, it is now also possible to configure NowSMS to route all e-mail communication through a shared POP3 or IMAP mailbox.

IMAP, with a service that supports the IDLE command, such as GMail, is recommended, as this allows e-mail messages to be pushed to NowSMS automatically as they are received. (POP3 requires periodic polling of the mailbox to retrieve new messages.) E-mail related settings have been moved to a separate configuration tab. E-mail services are provided by the MMSC service, which must be active. (GMail configuration notes: use Server Type IMAP with SSL/TLS. IMAP server is imap.gmail.com:993 and SMTP server is smtp.gmail.com:587.)

When sending an SMS or MMS to the shared mailbox via e-mail, the phone number of the recipient must be specified at the start of the subject line of the message.

Configuring NowSMS as an SMTP server provides more power and flexibility as the phone number is part of the e-mail address.  However, this additional configuration option provides an additional option that is better suited for some deployment scenarios.

SMPP Server Enhancements

Numerous improvements have been made to the SMPP Server interface built into NowSMS.

Individual clients can be configured to use different formats for message delivery, including different default character sets, whether port numbers and segmentation are sent via TLV or UDH parameters, whether or not to use data_sm format for message delivery, and async mode support for message delivery.

Message speed limits for accepting messages from an SMPP client are also more accurately enforced at higher speeds.

Mobile Operator MMS APN Settings

NowSMS and NowSMS Lite are frequently used in configurations that include GSM Modems. We’ve updated our list of mobile operator MMS settings to include the preferred WAP2/HTTP proxy settings for several hundred mobile operators around the world.

If you are not currently using WAP2/HTTP settings, you might not be receiving all MMS messages sent to the GSM modem, as one of our customers recently encountered.

Updated settings are included in the latest release, but you can also find more information in the article Mobile Operator MMS APN Settings.

Using PHP Scripts to Extend NowSMS

PHP scripts are a great tool for integrating NowSMS into another application environment, or extending the functionality of NowSMS.
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.

Since 2011, NowSMS has supported an interface that could work with a local copy of PHP without requiring a separate web server. However, this interface has relied on environment settings that were expected to be set by the PHP installation program, which were sometimes mysteriously missing. To better address these issues which are beyond our control, the new version of NowSMS is far more robust in detecting and enabling local PHP installations.

Click here for more information on NowSMS and PHP.

Click here for more information about accounting and routing callbacks.

An updated release of NowSMS is now available for download. Version 2013.11.15 is a critical update for customers using MMSC functionality.

This update fixes two different denial of service problems and improves recovery handling of unexpected problems. One problem was new to the 2013.09.26 release and can be triggered by a corrupt message received via an MM4 connection. The other problem affects all previous versions of NowSMS and can be triggered by a corrupt MM1 message submission that is to be routed externally via MM4 or MM7.

This release also corrects a problem where some To/Cc recipient headers were lost or incomplete for MMS group messages received via an MM4 interconnect.

Additional details on this release can be found in our changes log at http://www.nowsms.com/download/changes.txt.

For a summary of major new features introduced in recent releases, please see http://www.nowsms.com/nowsms2013.

The trial version download can be used to update an existing installation: http://www.nowsms.com/download-free-trial

This article provides troubleshooting advice when sending SMS messages with NowSMS and experiencing one or more of the following issues:

a.) Some characters such as @, $, £ or € are not correct.

b.) Some or all messages are truncated or garbage (possibly only messages over a certain length).

c.) Some accented characters are not correct (è, é, etc.)

d.) Some or all Greek characters are not correct (Δ, Φ, etc.)

e.) Messages containing non-English/Latin characters are not correct (Arabic, Chinese, Japanese, Korean, etc.)

f.) Emoticon/Emoji characters are not correct ( , etc.)

One of the most frustrating issues facing some SMS implementations is character set issues, especially for SMPP environments, where different providers use different character sets and tend to be oblivious about how their implementation differs from others.

The NowSMS approach is to offer as much flexibility as we can with regard to character set handling, however limitations of some provider implementations may require compromises and trade offs.

In this post, we’re going to focus on common issues, troubleshooting and configuration options to address commonly encountered problems.

Unfortunately, the process of finding the best settings for use with your provider can often require trial and error testing methods.

For a technical discussion of these issues, see http://www.nowsms.com/long-sms-text-messages-and-the-160-character-limit

The first step of troubleshooting is to perform test messages containing problem characters from the NowSMS web interface only, using the built in “Send Text Message” form. This is very important for troubleshooting. It is necessary to determine whether the character encoding problem is with input from a client to NowSMS or with output from NowSMS to the SMSC provider.

If the characters are sent correctly using the “Send Text Message” form, then the encoding issue is input related. If using HTTP, NowSMS expects UTF-8 character encoding to be used for all text (which is the character set that the web form is configured to use). If you cannot convert your text to UTF-8, you can add a parameter to your HTTP request to tell NowSMS what character set is being used. More information can be found here: http://www.nowsms.com/discus/messages/1/5754.html

This article will focus on output issues where there is a character set issue between NowSMS and the SMSC provider, or in other words, issues where the character problem can be recreated using the built-in “Send Text Message” form.

We recommend working through each of these issues in sequence. Verify that you are not experiencing the problem described before moving on to the next issue, as the solution may be related to an issue that you do not realise you are experiencing.

a.) Some characters such as @, $, £ or € are not correct.

The character set used for SMS is different than the standard character sets used by computers.

By default, NowSMS uses the GSM SMS character set encoding over SMPP. However, some SMPP providers expect one of the computer character sets to be used.

Test first with @ and $ characters. If those characters do not work, go into the “Advanced Settings” for the SMPP connection in NowSMS and try changing the “SMSC Character Set” to “iso-8859-1 as Default”. Note that in order to save and activate that setting change it is necessary to press “OK” twice then “Apply” when you are returned to the “SMSC” list. (If NowSMS asks if you wish to test the SMSC connection, it is ok to answer “No”.) Wait about 60 seconds for the server to activate the settings change and try another test message.

Other character sets can also be tried, but they are more rarely used.

Assuming that @ and $ are correct, but the € character is not correct, try changing the “SMSC Character Set” to “iso-8859-15″. If this causes problems, it may be necessary to manually add a setting to the SMSGW.INI file. Under the [SMPP - server:port] section header of SMSGW.INI, which contains your SMPP configuration information, there should be a setting SMSCCharset=iso-8859-15. Below that setting, on a new line add SMSCCharsetDefault=Yes

b.) Some or all messages are truncated or garbage (possibly only messages over a certain length).

The @ character is encoded as a NULL value in the GSM SMS character set, so if messages are truncated where the @ character should appear, this is a good indication that the provider expects iso-8859-1 or iso-8859-15 as described in the previous section.

If simple short text messages containing only English alphabet characters appear as corrupt, then it is possible that you are interfacing with an older SMPP server that expects all text messages to be in 7-bit packed encoding, which is the actual over the air format. Under the “Advanced Settings” for the SMPP connection in NowSMS, enable the “Encode text messages with 7-bit packing” setting. Note that in order to save and activate that setting change it is necessary to press “OK” twice then “Apply” when you are returned to the “SMSC” list. (If NowSMS asks if you wish to test the SMSC connection, it is ok to answer “No”.) Wait about 60 seconds for the server to activate the settings change and try another test message.

If only longer messages are impacted … then try the following:

If long messages produce garbage output, under the “Advanced Settings” for the SMPP connection in NowSMS, change the “Encode long text messages with 7-bit packing” setting. Different versions of NowSMS have different defaults for this setting. Most SMPP servers will want this setting disabled, but there are also a sizable number that want this setting enabled.

If the messages contain some garbage characters mixed in with the text, or the receiving device sees multiple message segments instead of one long message, try enabling “Use TLV Parameters for port numbers and segmentation”. By default, NowSMS builds GSM User Data Header (UDH) to encode message segmentation information. Some providers expect segmentation to be encoded using optional TLV parameters instead.

Some providers might prefer that you do not segment long messages, but instead send the entire long message in one transaction and allow the provider to perform segmentation for delivery. This is often referred to as the “message payload” method. This setting can be enabled in NowSMS by enabling “Use WDP Adaptation for WAP Push and MMS” and disabling “Use TLV Parameters for port numbers and segmentation”.

Another situation that can affect only some long messages is that some SMPP providers have different encoding expectations if a message contains “message class” encoding. Normal text messages will have a DCS/data_coding value of 0 (standard text) or 8 (Unicode text). If the problem messages show a different DCS value in the NowSMS logs, refer to the following discussion threads for information on advanced settings: http://www.nowsms.com/discus/messages/1/71597.html http://www.nowsms.com/discus/messages/1/71862.html

c.) Some accented characters are not correct (è, é, etc.)
and/or
d.) Some or all Greek characters are not correct (Δ, Φ, etc.)

Refer to the GSM character set table at http://www.nowsms.com/long-sms-text-messages-and-the-160-character-limit

Are the characters in the GSM character set?

If they are not in the GSM character set, NowSMS is using Unicode format (DCS/data_coding=8) to encode the message, and you may need to speak with your provider about enabling Unicode support. It is possible to to disable automatic Unicode detection for SMS text messages submitted via HTTP. When DisableHttpUnicodeSMS=Yes is set under the [SMSGW] header of SMSGW.INI, NowSMS will disable automatic Unicode detection and will replace Unicode characters with a close equivalent, or with – or ?.

If the characters are in the GSM character set, it is possible that you are using the iso-8859-1 or iso-8859-15 character set, and those characters are not in that character set. In NowSMS 2014.02.17 and later, there are configuration settings that can force unicode encoding to be used for these characters. Under the [SMSGW] header, add either TestUnicodeSMSForISO88591=Yes or TestUnicodeSMSForASCII=Yes. The latter setting forces Unicode if a message contains characters outside of the ASCII (7-bit subset of iso-8859-1) character set.

The upside of forcing Unicode encoding is that no characters are lost. The downside is that segmentation occurs for these messages at 70 characters instead of 160.

e.) Messages containing non-English/Latin characters are not correct (Arabic, Chinese, Japanese, Korean, etc.)

NowSMS uses Unicode format (DCS/data_coding=8) to encode a message if it contains any characters outside the 7-bit GSM character set. You may need to speak with your provider about enabling Unicode support. It is possible to to disable automatic Unicode detection for SMS text messages submitted via HTTP. When DisableHttpUnicodeSMS=Yes is set under the [SMSGW] header of SMSGW.INI, NowSMS will disable automatic Unicode detection and will replace Unicode characters with a close equivalent, or with – or ?.

f.) Emoticon/Emoji characters are not correct ( , etc.)

How very sad for you.

Emoticon and Emoji encoding is discussed in excruciating detail at http://www.nowsms.com/emoticons

NowSMS Beta Release – Android Phone Modem Support

New versions of NowSMS and NowSMS Lite will soon be available, and we are looking for beta release feedback. This beta will primarily be of interest to customers who are using, or are interested in using, modem devices to send and receive SMS and MMS messages via NowSMS.

The new release will include support for using most standard Android phones to send and receive SMS and MMS messages. (We have performed internal testing with devices running Gingerbread version 2.3 thru KitKat version 4.4.)

The beta release is expected to be available starting Wednesday, April 16. To request access to the beta, please send an e-mail to nowsms@nowsms.com. Additional details will be posted in the support forum area of the NowSMS web site on April 16.

Supporting Android phones as modems is significant for several reasons:

• LTE Support – LTE based Android devices can provide higher speed support for MMS sending and receiving.
• Network Compatibility – Some mobile operators (and modem device manufacturers) assume that modems are used for internet access only and disable SMS and/or MMS support for modems. This is not an issue for Android phones.
• CDMA Support – For years, US based customers have asked us about modems that can support Verizon and Sprint. Android phone support allows us to support those network operators using both CDMA and high speed LTE.
• Broad Device Availability – For customers interested in trying NowSMS, it is far easier to locate or acquire an Android device than a conventional modem.
• MMS Performance – With conventional GSM modems, MMS performance is limited by the mode switching required to switch between data and SMS channels. There are no mode switching delays mixing SMS and MMS traffic on Android devices.
• Multiple Modems – USB connectivity (and driver quality or lack thereof) is a major limitation for systems with multiple conventional GSM modems. For Android phones, the NowSMS server connects to the Android phones over WiFi, providing far greater performance for NowSMS to simultaneously control multiple modems. Modems can even be located in different physical locations to maximize signal strength. (The NowSMS server communicates over WiFi to a new app running on the Android phone.)

Additional New Features

For this update, we have focused on improving features that are of interest to modem based configurations. Some highlights:

Simplified Setup & Configuration

No more messing with finicky USB modem drivers and meddlesome modem manufacturer software.

MMS Settings can be automatically determined for most configurations.

NowSMS setup simplified for defining integrated SMS and MMS related settings in one dialog.

Modem discovery/selection in either NowSMS or NowSMS Lite

SMS and MMS Modem Settings Integration

Improved Bi-Directional E-Mail to SMS/MMS Gateway

If you’re looking to use connect office workers on e-mail with mobile workers or customers, options have been added to simplify setup. A single gateway mailbox on Gmail can replace the need for setting up a separate e-mail domain. And SMS or MMS replies can be automatically routed back to the original e-mail sender.

E-Mail to SMS and MMS can also make use of distribution lists, making it easier to get your content to interested subscribers.

E-Mail Gateway Configuration

More Powerful 2-Way Commands

We’ve kept what works, but made it easier to get started. Simple keyword setup allows static text or image content to be sent in reply to a received message.

Keyword actions can also add or remove a subscriber from a distribution list, or forward a received message to an e-mail address.

2-Way Command Options

More Information

For more information visit:

http://www.nowsms.com/discus/messages/1/72365.html