Disclaimer: This information is neither validated nor endorsed by Check Point Software Technologies.

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

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

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

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

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

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

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

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

The Alcatel One Touch X200 and X060 USB Modems are good (but not great) modems to use with NowSMS to send and receive SMS and MMS messages.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Frequencies supported by the Alcatel One Touch X200:

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

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

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

SMS Delivery Receipts are NOT supported.

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

A recent posting on the NowSMS Discussion Board has some interesting information on sending an SMS a link within an Excel spreadsheet.

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

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

Here’s what I did …

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

I then associated the following code with my command button:

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

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

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

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

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

NowSMS supports the Open Mobile Alliance (OMA) Push Access Protocol (PAP), which allows other applications to use NowSMS as a WAP Push Proxy Gateway (PPG).

If you are using NowSMS in a laptop with an available ExpressCard slot, the Novatel Wireless Merlin XU870 ExpressCard Modem is a good modem to use with NowSMS to send and receive SMS and MMS messages.

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

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

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

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

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

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

Frequencies supported by the Novatel Merlin XU870:

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

One of the more interesting technical support incidents of the past week comes from Mohit Kumar Sethi at 3i Infotech Consumer Services Ltd.

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

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

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

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

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

But back to Mohit’s problem…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

An e-mail notification service is available for NowSMS software update information.  To receive e-mail notifications for NowSMS software updates, please subscribe using the following Google FeedBurner link.

This document provides release history information for the current release version of the Now SMS & MMS Gateway, which can be downloaded at http://www.nowsms.com/download-free-trial.

This document covers changes between the last major 2009 release and version 2010.02.09.  An interim update may be available at the following link:   http://www.nowsms.com/nowsms-update.

The release history information provides additional information on configuration settings that have been added to address unusual configuration requirements.

2010-02-03:

* Fixes for UseRouteQueues=Yes setting when “SMSCRoute=” is set by a PreAuth SMS Accounting callback.

2010-01-27:

* 2-way SMS: Fix for problem where SMPPOptions settings and service type were not preserved when recombining a received multipart SMS for passing to a 2-way command.

* MMS Gateway/MM1: Fix for problems routing MMS delivery reports back to an MM7 connection if the MMSC host name is not configured (which is always the case in NowSMS Lite). Also fix a problem where MMS delivery reports were not automatically routed to the default route configured for the modem’s MMS receive settings.

* SMS Gateway/SMPP Client: Update configuration parameter that allows the “users” directory to be moved to another location other than beneath the NowSMS program directory. This directory contains queues of received messages waiting for SMPP or POP3 clients, as well as user specific log files. Under the [SMSGW] header in SMSGW.INI, use UsersDir=d:\path\ or UsersDir=\\Server\Volume\path\ to specify the location of the SMS “users” directory. When this parameter is set, the “SMS Users” database files (SMSUSERS.D2A and SMSUSERS.D2I) will also be located in this directory (by default, when this parameter is not set, these files are in the NowSMS program directory). With this release, it is now possible to separate the queued messages and log files from other user related data. Under the [SMSGW] header, use UsersQDir=d:\path\ or UsersQDir=\\Server\Volume\path\ to specify the location of the user directories that will hold queued messages only. Under the [SMSGW] header, use UsersLogDir=d:\path\ or UsersLogDir=\\Server\Volume\path\ to specify the location of the user directories that will hold log files. Other user directories and files will be stored relative to the “UsersDir=” setting, or in their default location if “UsersDir=” is not present.

* SMPP: Add SMSC specific configuration option to suppress TLV receipt parameters when delivery receipts are routed to an outbound SMSC connection (this would generally only happen when the ReRouteReceived option is used). Under the [SMPP - server:port] header of SMSGW.INI, if you want to suppress the receipt TLV parameters for messages routed to this server, add IgnoreReceiptTLV=Yes.

2010-01-19:

* SMS Gateway: Add a configuration option to add separate queues for explicitly routed messages. In SMSGW.INI, under the [SMSGW] header, add UseRouteQueues=Yes.

* SMS Gateway: Add a configuration option to possibly speed up receiving of SMS messages when accounting callbacks are enabled and SMPP async mode is enabled for a connection. When this configuration option is enabled, inbound SMS message processing and accounting callbacks are moved to a separate thread. To enable this setting, edit SMSGW.INI, and under the [SMSGW] header add AsyncReceiveMessages=Yes. (Note: This setting is still considered experimental.)

2010-01-06:

* MMSC: Fix for problem with MSISDN header parsing where the MMSC was looking for both the X-MSISDN header and a value configured for the “MSISDNHeader=” setting, when it should only be looking for the “MSISDNHeader=” setting.

2009-12-24:

* SMS Gateway: Fix for problem where if “Separate outbound message queues” for each user is not enabled, NowSMS would not send out any SMS messages that originated via SMTP.

2009-12-22:

* SMS Gateway: Fix for problem where NowSMS would keep re-initialising a modem if the user had never edited and saved properties for the modem after the initial add.

2009-12-21:

* SMPP: If routing a delivery receipt via an outbind SMSC connection, use esm_class of 8 in submit_sm. (Previously, a value of 4 was being used, which is not valid in submit_sm.) Also add a configuration option to suppress TLV paramters (message_state and receipted_message_id) for delivery receipts routed via an outbind SMSC connection. To suppress these TLV parameters, edit SMSGW.INI, and under the appropriate [SMPP - server:port] section header, add IgnoreReceiptTLV=Yes.

* SMPP: Add message_id to data_sm_resp if we receive a data_sm from an outbind SMSC connection, and the message is rerouted to another outbind SMSC connection because of a “ReRouteReceived” configuration setting.

* SMS Gateway: Update preferred service_type handling for routing particular service_type values to specific SMSC connections to support pattern matching and “best match”. See http://www.nowsms.com/discus/messages/1/42107.htm and http://www.nowsms.com/discus/messages/1/24460.html.

* Add option to disable writing anything to the Windows Event Log. Add DisableEventLog=Yes under [SMSGW] header in SMSGW.INI.

* SMS Gateway: Allow retry parameters to be specified on a per-SMSC connection basis, so that different connections can have different retry settings. If any of the following retry parameters is found in the SMSC specific section of SMSGW.INI, it will override the default setting under the [SMSGW] header: RetryDelay, RetryDelayMultiplier, RetryDelayAfterAttempts, RetryDelayMax, RetryMaxAttempts, InitRetryDelay, InitRetryDelayMultiplier, InitRetryDelayAfterAttempts, InitRetryDelayMax.

2009-12-08:

* MMSC/MM4: Implement checks to prevent circular routing for MM4 interconnects. If a message is received via an MM4 connection, and the MMSC determines that its delivery path to the recipient is via that same MM4 connection, the message will be rejected with a negative response in the MM4_forward.RES. For compatibility with previous releases, this check can be disabled with the setting DisableCircularRoutingCheck=Yes in MMSC.INI.

2009-12-01:

* MMSC: Fix for MMSUSER.EXE -quotareport listing up to 1000 blank user entries after the last user.

2009-11-25:

* SMS Gateway: Fix for a problem where individual parts of a multipart message were not routed out via the same SMSC connection if NowSMS was able to fully route one part before the next part was received.

* SMPP: Add a configuration option to override the character set for received SMS messages. A customer encountered a situation where the SMSC was encoding text using the iso-8859-1 character set. However, the SMSC was setting the character set flag in the message to indicate that text was using the GSM character set. NowSMS was configured to use the iso-8859-1 character set with this SMSC, however, since the character set was explicitly set as GSM in the received message, NowSMS could not decode the text properly. To address this issue, it is possible to add SMSCCharsetReceiveTextOverride=Yes under the [SMPP - server:port] section of SMSGW.INI. When this parameter is present, NowSMS will always interpret received text messages as being encoded in the character set configured for the connection.

* SMPP: Add a configuration setting to allow a default PID value to be used for all messages routed to a specific SMSC connection. Under the [SMPP - server:port] section of SMSGW.INI, add DefaultPID=XX, where XX is the PID value in hex.

2009-11-04:

* MMSC: When the sender of an MMS message is an e-mail address (instead of a short code or phone number), and the message arrives via a VASP connection, requesting a delivery receipt, the MMSC would always try to send the delivery receipt back via e-mail. This was only an issue if the MMSC was delivering the message directly, if it was routing to an upstream MMSC connection, delivery receipts back to an e-mail recipient would be routed correctly.

* SMS Gateway: Add a configuration option to use 16-bit reference numbers when generating concatenated multipart messages. By default, NowSMS uses 8-bit reference numbers, which allows the most characters to be fit in a single SMS. However, a customer observed that when sending binary messages to a Java application on many Motorola phones, one byte of data per message segment would be lost when using 8-bit reference numbers due to a bug in the phone software. When 16-bit reference numbers are used, message length per segment rules change. For long text messages, instead of 153 characters per segment, only 152 characters per segment can be achieved. For Unicode messages, instead of 67 characters per segment, only 66 characters per segment can be achieved. For binary messages, 133 bytes of binary data can be included per segment, instead of 134 bytes. To enable 16-bit reference numbers, edit SMSGW.INI, and under the [SMSGW] section header, add ConcatRef16Bit=Yes. Note that when this setting is applied, 16-bit reference numbers are only used when NowSMS performs the segmentation (message submitted either via HTTP, or via SMPP using a single message_payload submission) … NowSMS does not resegment messages that have already been segmented by the submitting client.

2009-10-28:

* SMPP: Add SMPP character support for an unusual “Roman-8″ character set needed for a specific SMSC.

2009-10-23:

* GSM Modem: Add code to detect a system waking up from sleep or hibernation where we may need to reset the modem.

* SMPP: Add configuration setting to prevent NowSMS from remapping GSM message class DCS values which are invalid in SMPP to valid SMPP values. To apply this setting for a specific SMSC, edit SMSGW.INI, and under the SMSC specific section (e.g., [SMPP - server:port]), add emapMessageClassDCS=No.

2009-10-21:

* SMS/GSM Modem: For messages received via GSM modem, if a phone number property is not set for the modem, read the phone number from the modem and apply it as the received phone number.

* SMSLite: Configuration program was not allowing the “Route SMS to local user” setting to select users.

2009-10-19:

* SMS/GSM Modem: Fix for problem initialising Telit HSPA Modem. Previously, attempts to initialise modem were returning error: “Error initializing modem – 0″

2009-10-12:

* MMSC: EnableReadReceipt=No was disabling read receipts from being generated by local recipients, but it was not disabling the read receipt request from being routed to external recipients. It now blocks both.

2009-10-07:

* SMPP Server: Fix for change in 2009.10.01 version which caused server to accept messages from an SMPP client even if a user was over quota.

2009-10-01:

* GSM Modem: More GSM modem handling updates.  Added code to reset the modem after persistent errors sending SMS or MMS messages to try to recover “hung” modems. MMS sending updated to address an issue where if a modem was removed/reinserted, the MMS part of NowSMS could not recognize the modem again until the service restarted. (This could also happen with buggy modems that restart themselves periodically.) An additional option was added to the GSM modem configuration to trigger NowSMS to restart the server if a modem becomes unresponsive and NowSMS is unable to access the modem. (Note: NowSMS retries for about 15 minutes before triggering a reboot when this option is enabled.)

* SMPP/WDP Adaptation: Fix for 2009.06.30 change. If BinaryDCS override is not specified for the SMPP connection, and WDP Adaptation is being used, continue to remap DCS value 0xF5 to 4, as was done in earlier releases.

* SMPP Server: When accepting messages from an SMPP client, if the client specifies TON=1 (international), but the address starts with “0″, assume that the number is in local format, not international.

2009-09-16:

* MMSC/MM4: Work-around for situation where MM4 delivery reports were not being accepted because the recipient address (original sender) for the delivery report was not being specified in the “RCPT TO:” command. Instead, the other MMSC was specifying the MMSC system address in the “RCPT TO:” command and only included the original recipient in the “To:” header of the message.

2009-09-15:

* SMS Gateway: Fix for an exception error that could occur with segmented SMS messages submitted to recipient phone numbers longer than 70 characters. Problem most frequently occurred with multiple outbound SMSC connections.

* Receiving MMS via GPRS Modem: Fix for problem where when received SMS messages are being routed to a local user, NowSMS would also route MMS notifications to that local user account instead of processing them as received MMS messages.

2009-09-08:

* MM7: Add configuration option to allow selected MM7 status codes to be classified as success or retry status codes. By default, NowSMS accepts only StatusCode 1000 as an inidication of successful message submission. To add additional status codes, edit VASPOUT\accountname\VASP.INI, and under the [VASP] header, define SuccessStatusCodes=1000,1001,1002 (comma delimited list of status codes). Similarly, NowSMS considers all errors except 2001, 3003, 4000, 4006 and 4007 to be permanent status errors. If NowSMS receives a StatusCode response with any other value, the message submission will not be reattempted (3003 is a special status code case indicating that the MMSC only accepts one recipient at a time). To add additional StatusCode responses that should be treated as temporary errors, edit VASPOUT\accountname\VASP.INI, and under the [VASP] header, add RetryStatusCodes=2001,4000,4006,4007 (comma delimited list of status codes, include the default StatusCodes that should be retried).

2009-08-31:

* SMPP: Add SMPP character support for the unusual “ASCII 437″ code page that is used by Telstra.

* SMPP: Add configuration setting to set the initial SMPP sequence_number value to be used by a connection as a random value. To enable this setting, edit SMSGW.INI, and under the [SMSGW] header add SMPPSeqRandom=Yes.

2009-08-26:

* GSM Modem Handling: If errors occurred when sending MMS messages via a modem route, the MMSC would not timely release the modem to allow SMS sending to continue.

* SMPP: Fix for improper sequence_number generation issues.

* Add “BCC” option for sending an MMS message via the web interface. If using NowSMS proprietary URL submission, include “MMSBCC=Yes” to force recipients to be BCC.

* SMS Gateway/SMPP Client: Update configuration parameter that allows the “users” directory to be moved to another location other than beneath the NowSMS program directory. This directory contains queues of received messages waiting for SMPP or POP3 clients, as well as user specific log files. Under the [SMSGW] header in SMSGW.INI, use UsersDir=d:\path\ or UsersDir=\\Server\Volume\path\ to specify the location of the SMS “users” directory. When this parameter is set, the “SMS Users” database files (SMSUSERS.D2A and SMSUSERS.D2I) will also be located in this directory (by default, when this parameter is not set, these files are in the NowSMS program directory). With this release, it is now possible to separate the queued messages from other user related data and logs. Under the [SMSGW] header, use UsersQDir=d:\path\ or UsersQDir=\\Server\Volume\path\ to specify the location of the user directories that will hold queued messages only. Other user directories and files will be stored relative to the “UsersDir=” setting, or in their default location if “UsersDir=” is not present.

* MMSC/MM4: Add the ability to use different source/sender domain names for different groups of users. This may be useful when multiple mobile operator networks are serviced by a single MMSC. To specify the outbound domain name, edit VASPOUT\accountname\VASP.INI for the outbound MM4 connection … creating a [DomainMapping] section. Within this section, specify address pattern to domain name mappings using the following format addresspattern=domain.name (e.g., +111*=domain1.com). Note: To support these additional domain names when receiving messages, add domain name alias settings under the [MMSC] section of MMSC.INI using the format DomainNameAlias1=domain1.com … DomainNameAlias2=domain2.com … etc.

2009-08-20:

* GSM Modem Handling: Internal updates for improved performance and compatiblity. Change the default receive polling interval to 3 seconds when “Direct to Modem” is the “SMS Message Storage” type. The polling interval is set to 2 seconds for other “SMS Message Storage” types (prior to NowSMS 2009, it was always 1 second). To change the default add ReceivePoll=##, where ## is the number of seconds, under the appropriate [Modem - driver name] section header of SMSGW.INI. Modem polling logic also optimised to be less resource intensive on the modem. If this change causes problems receiving messages with older phone modem implementations that worked with previous version of NowSMS, add OldPollingLogic=Yes under the appropriate [Modem - driver name] section header of SMSGW.INI.

* MMSC: When routing MM7 to MM1, do not encode “Content-Disposition:” headers in the MM1 message, as this seems to confuse some operator MMSCs.

2009-08-15:

* 2-way SMS processing: Non-delivery receipts generated by NowSMS when an SMSC connection rejected a message were being marked with a “.IN” extension instead of a “.REC” extension. While not necessarily a problem, this could cause delays for other “.IN” messages being processed. These receipts are now marked with a “.REC” extension so that they will be processed in the 2-way SMS receipt queue instead of the normal inbound message queue.

2009-08-14:

* Multimedia Content Push: WML format is used by default. HTML format is only used if the receiving client does not support WML.

* Internal changes (updated debug log information) for 2-way SMS processing in the SMS-IN directory.

* GSM Modem Handler: Improved compatibility with SonyEricsson USB modems (especially MD300).

2009-08-05:

* Multimedia Content Push: Fix XHTML generated for multimedia content push. Update install to include missing CSS file for XHTML version of multimedia content push.

* SMS Gateway: Modem handling – Change “Default” and “Direct to Modem” handling to prefer SIM message storage.

2009-07-29:

* Fix for 2009 changes to multimedia WAP push causing problems displaying content that includes Unicode text.

2009-07-23:

* SMS Gateway: When NowSMS generates a non-delivery receipt because an upstream SMSC connection has rejected a message, the non-delivery receipt was not being logged. It is now logged to the SMSIN log file.

* SMS Gateway: Add configuration option to suppress the creation of “.ERR” files when an SMSC connection rejects a message. To suppress these files, edit SMSGW.INI, and under the [SMSGW] header, add ErrorQRetainDays=0.

2009-07-21:

* MMSC: Fix for AccountingKeepAlive=No and RoutingKeepAlive=No settings not working for MMS accounting and routing callbacks. Use of these settings would cause a handle leak and after a period of time, the MMSC would no longer be able to accept or initiate connections.

When the NowSMS MMSC is used in environments with mobile number portability (MNP), the MMSC may need to query a database to determine whether a recipient is local to this MMSC or if it belongs to another operator.

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

Mobile Number Portability (MNP) and the NowSMS MMSC

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

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

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

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

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

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

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

One important consideration when charging for MMS messages is whether or not the user is roaming. The NowSMS MMSC can provide this information to the MMS accounting callbacks, however the requisite information is not included in the MMS accounting callbacks by default.

An interim update release of NowSMS is available for download at http://www.nowsms.com/download/nowsmsupdate.zip.

One of the standard capabilities of NowSMS is the automatic mapping of receipt message IDs when routing messages to an upstream SMSC connection.

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

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

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

HTTP Protocol Information

• Sending SMS Text Messages over HTTP

• Sending WAP Push Messages over HTTP

• Sending WAP Push Messages using PAP over HTTP

• NowSMS HTTP URL Parameter Reference

• Sending MMS Messages over HTTP

• 2-Way: Receiving SMS Messages over HTTP

• 2-Way: Receiving MMS Messages over HTTP

• Search the NowSMS Web Site for 2-Way SMS

• Search the NowSMS Web Site for 2-Way MMS

PHP Scripts for Sending SMS & MMS

• Sending SMS Text Messages with PHP

• Sending MMS Messages with PHP

• Sending OMA Client Provisioning Messages with PHP

• 2-Way: PHP Examples for Receiving SMS

• 2-Way: Receiving MMS with a PHP Script

• PHP Related Postings on the Technical Blog

• Search the NowSMS Web Site for PHP

Java Examples for Sending SMS & MMS

• Sending SMS Messages from Java

• Sending WAP Push Messages from Java

• Sending MMS Messages from Java

• Java Related Postings on the Technical Blog

• Search the NowSMS Web Site for Java

.NET Examples for Sending SMS & MMS

• Sending MMS Messages from VB .NET

• Sending MMS Messages from C# .NET

• .NET Related Postings on the Technical Blog

• Search the NowSMS Web Site for .NET

Command Line Interface for Sending SMS & MMS

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

• Sending SMS Messages

• Sending WAP Push and Binary SMS Messages

• Sending MMS Messages

• Sending OMA Client Provisioning Messages

• Command Line Interface Related Postings on the Technical Blog

• Search the NowSMS Web Site for Command Line Interface

An interim update release of the Now SMS & MMS Gateway is currently available at http://www.nowsms.com/download/nowsms20101104.zip.  Use the executable file in this ZIP to update an existing NowSMS installation.

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

Highlights of this update:

1.) SMS Gateway: Performance enhancements for processing large message queues, especially when there are 4 or more outbound SMSC connections.

2.) SMS Gateway: Improved performance for accepting HTTP message submissions, HTTP keep-alive sockets now supported.

3.) SMS Gateway/SMPP Client: Added the capability to define the number of transmitter, receiver and/or transceiver connections to be allocated for a single SMPP connection, without requiring multiple duplicate connections to be defined.

4.) SMPP Server: Support for using SMPP Asynchronous mode to speed the delivery of messages to SMPP Clients when NowSMS is acting as an SMPP Server.  Also an improvement message ID generation logic to prevent duplicate message IDs (SAR-phonenumber-x-x-x format) from being generated.

5.) MMSC: Fix for corrupt message problems that could trigger internal restarts of the MMSC service when processing such a message.

6.) MMSC/MM4: Tolerance improved in decoding received messages where the Content-Location header does not conform to the relevant SMTP specifications, which previously resulted in some users receiving occasional corrupt messages over some MM4 interconnections.  Forwarding of these corrupt messages is suspected in the corrupt message problems that triggered internal restarts of the MMSC service.  Also, fix foran  interoperability problem that was causing some customers problems interconnecting with NTT DoCoMo Japan.  Received messages from this interconnect were not strictly following the 3GPP TS 23.140 Message-ID and Transaction-ID formats.  NowSMS used to correct the encoding problem when sending acknowledgments, but now returns acknowledgments with these ID values in the same format in which they were received, even if the values are invalid per the 3GPP TS 23.140 specification.

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

* E-Mail to SMS: Translate Greek capital letters to visually equivalent 7-bit characters in attempts to send SMS messages out using 7-bit encoding. (The NowSMS web interface already does this.)

* MM7 Client: Change Content-Type: text/xml; charset=”utf-8″ to Content-Type: text/xml; charset=utf-8 to address a compatibility problem with a particular operator MMSC. (Whether or not this parameter is quoted should not matter. Removing the quotes should not cause a problem with other MMSCs.)

2010-10-28:

* SMPP Client: Fix for some BinaryDCS= values not working properly, especially BinaryDCS=2. If BinaryDCS=2 was set for a connection, NowSMS would garble the data.

2010-10-22:

* SMPP Client: Fix for a problem introduced in mid-2010 where message receipt IDs were not properly evaluated if the receipt was received two or more days after the message was originally sent.

* SMPP Server: Add preliminary support for NowSMS acting as an SMPP server to use async mode to deliver messages to SMPP clients (NowSMS has previously supported async mode in the other direction, where NowSMS is the SMPP client). This can provide increased performance in delivering messages to connected SMPP clients, provided that the client can support SMPP async mode. To enable SMPP async mode for all clients, add SMPPServerAsyncWindowSize=## to the [SMSGW] section of SMSGW.INI. Alternatively to enable or disable for selected clients, add an [SMPPServerAsyncWindowSize] section to SMSGW.INI, and specify AccountName=## to set the async window size for a specific SMS User account. (A window size of 0 disables async mode.)

2010-10-18:

* SMS Gateway: E-mail alerts now support multiple recipients, separated by a comma.

2010-10-13:

* MMSC: When NowSMS generates an MM7 error response, it was not encoding the error in an a SOAP envelope <fault> element, as required by Section 8.7.8.3 of 3GPP TS 23.140. (Note: The issue is not as cut and dried as it may seem, as the MM7 element defintions for the error response are in conflict with this Section 8.7.8.3. We are choosing to follow Section 8.7.8.3 and assume that the definitions that conflict with it are mistakes in the specification. Further discussion of this issue is at http://www.nowsms.com/discus/messages/485/60182.html.)

2010-10-04:

* SMPP – Fix for a problem where recent versions have not properly passed the “Bind TON”, “Bind NPI” or “Address Range” parameter in SMPP connection tests from the configuration dialog when initially defining a new SMSC connection.

* SMS Gateway: Initial HTTP Keep-Alive socket support in the SMS gateway in the last release caused a problem for “/provision” requests. This problem has been resolved.

* MMSC: Add configuration option to block routing callback for short codes (many routing callbacks expect standard phone numbers). If ForceRoutingCallback=Yes is set in the MMSC.INI, then ForceRoutingCallbackShortCodes=No can be set to exclude short codes from the routing callback. Note: The default maximum short code length is 6 digits, this can be adjusted with the ShortCodeMaxLength=## setting. (All settings referenced in this description are in the [MMSC] section of MMSC.INI.)

2010-09-30:

* SMS Gateway: HTTP Keep-Alive sockets are now supported for HTTP submissions to offer improved performance. If this causes a problem for some applications, keep-alive sockets can be disabled by editing SMSGW.INI and under the [SMSGW] header, adding EnableKeepAlive=No.

2010-09-21:

* SMS Gateway: The SMPPRejectErrorCodes setting described in http://www.nowsms.com/smpp-error-code-handling-in-nowsms can now be set on an individual connection basis. SMPPRejectErrorCodes= is now supported under individual [SMPP - server:port] section headers to allow settings that apply to only that connection.

* SMS Gateway: Improve performance of accepting new HTTP connections for message submissions.

* SMPP Server: Fix message id generation logic to avoid duplicate message IDs when accepting long messages from SMPP clients.

2010-09-14:

* SMPP: When receiving a delivery report from an upstream SMPP connection, if the TLV parameter message_state is not set, NowSMS would previously assume that the delivery report signals successful delivery and would generate TLV parameter message_state=2 if the delivery report is relayed to an SMPP client. Effective with this update, NowSMS now parses the text of the delivery report to determine the status. If the status cannot be determined, NowSMS will not generate a message_state parameter.

2010-08-23:

* MMSC: Add configuration setting to allow the SMTP host name to be set independently of the MMSC “Local Host Name”. To set the SMTP Host name, edit MMSC.INI, and under the [MMSC] header, add SMTPHostName=xxxx. If this parameter is not present, the “Local Host Name or IP Address” field will be used as the SMTP host name. (This setting was added on 2010-06-17, but the original implementation was for SMTP only, not MM4. It now also applies to MM4.)

* SMPP: Fix for a problem with delivery receipt handling for a delivery receipt that was received in Unicode text format.

2010-08-17:

* MMSC: Fix for an exception error that could trigger MMSC restarts when processing MMS to “SMS web link with code” conversions.

2010-08-13:

* MMSC/MM7: Fix for “MMSBCC=Yes” parameter not properly encoding recipients as “BCC” if routing externally via an MM7 or MM4 connection.

* SMPP: Add support for iso-8859-15 character set. This character set may be required if you are experiencing problems sending the Euro € character. When using the GSM character set, the Euro is encoded as an escape character followed by e. However, the Euro character is not actually defined in the iso-8859-1 character set. When NowSMS is configured to use the iso-8859-1 character set, it encodes the Euro with hexadecimal value 0×80, which is the standard encoding from the Microsoft Windows extension of iso-8859-1. However, some SMPP servers expect the Euro to be encoded as 0xA4, which is defined in the iso-8859-15 character set, a character set which was originally intended to be a replacement for iso-8859-1, but that did not see widespread implementation. When an SMPP connection is configured to use the iso-8859-15 (or iso-8859-1) character set, the default behaviour of NowSMS is to submit messages using a data_coding value of 3 to indicate iso-8859-1 encoding. Additional SMPP character set notes: 1.) Some SMSCs expect iso-8859-1 (or -15) encoding to be used, but do not understand the data_coding = 3 setting. For those environments, it is possible to manually edit SMSGW.INI, and under the [SMPP - server:port] section header for the SMPP connection, add SMSCCharsetDefault=Yes, which will tell NowSMS to use a data_coding value of 0 with the character set that is configured for the connection. 2.) If there are character set encoding problems receiving a message from a connection, note that NowSMS uses the configured character set for the connection for interpreting text messages only if the data_coding value is 0. If the data_coding value is 3, NowSMS will decode the text as iso-8859-1 (or iso-8859-15), regardless of the character set configured for the connection. If the data_coding value is 1, or a text encoding value other than 3, NowSMS will decode the text as using the GSM character set. To override this decoding behaviour for received messages, and force NowSMS to always use the character set configured for the connection, edit SMSGW.INI and under the [SMPP - server:port] section header for the SMPP connection, add SMSCCharsetReceiveTextOverride=Yes.

* SMPP Server: Support for SMPP clients connecting to the NowSMS server via SMPP using the iso-8859-15 character set has been added, similar to the settings described for outbound SMPP connections from NowSMS. Default settings for the NowSMS SMPP server character set can be configured under the [SMPP] header of SMSGW.INI. If there is a need to support SMPP clients that use different default character sets, it is possible to add additional user-specific section headers to SMSGW.INI. Under a header of [SMPP - username], the following parameters can be applied to a specific SMPP client account: SMSCCharset=IA5 (for GSM), iso-8859-1 or iso-8859-15; SMSCCharsetDefault=Yes (tells NowSMS to use a data_coding value of 0 with the configured character set), SMSCCharsetReceiveTextOverride=Yes (tells NowSMS to always use the character set configured for the user for text messages, even if the data_coding value implies a different character set is being used).

2010-08-03:

* SMS Accounting Callbacks: Add additional parameters to accounting callbacks, including SMPP “ServiceType” and “Validity” parameters.

2010-07-27:

* MMSC: Fix for a problem sending a message to a large number of MMS recipients, where a problem occurred because initial message recipients would receive the message notification before the MMS message file was closed on the MMSC. This caused message download failures unless MSISDNMatchRequiredForReceive=No was set under the [MMSC] header of MMSC.INI. (Most MMS clients would re-attempt download later and the message would be successfully delivered.)

* Web Interface/Send MMS Message: Fix for an exception error that could occur in the SMS gateway when sending an MMS message to a large number of recipients that include a “+” character.

2010-06-30:

* SMPP & MM7: Add configuration option to support alphanumeric recipients for SMS messages sent over SMPP and MMS messages sent over MM7. This is to support a provider that maintains server side distribution lists which are addressed as alphanumeric recipients. Alphanumeric recipients are only supported if AllowAlphaRecip=Yes is added to the [SMSGW] section of SMSGW.INI. (Fix problem sending to SMS recipients that include a “:” character.)

2010-06-28:

* MMSC/inbound MMS Messages: A new “MMSC Routing” option has been added for “MMSC VASP” definitions. “Local MMS Recipients Only” means that the connection will only accept messages that the MMSC can handle directly without routing to an external MMSC Routing (MM4, MM7) definition. “Local MMS Recipients Only” includes both local MMS users, as well as recipients that are automatically converted to WAP Push or SMS with web link (code). The purpose of the setting is to disallow selected MM4 or MM7 connections from being able to route externally via another MM4 or MM7 connection.

* MMSC: The MSISDNHeaderConvertToLocalNumber=Yes setting now affects both MMS headers and MMS messages that have been converted to SMS with web link (with code) for delivery, so that the message sender phone number is displayed in local number format instead of international number format.

* MMSC: Some temporary files (TEMPxxxxxxxx.TMP) were being created in the NowSMS program directory, and would fail to be deleted. These files are now properly created in the TEMP subdirectory and automatically cleaned up.

* SMS Gateway: When an HTTP message submission is rejected, it could be because the user is out of credits, has exceeded daily/monthly allowances, been denied by a response from an accounting callback, or an error has occurred processing an accounting callback. To aid in troubleshooting, the HTTP 403 error response now includes text that explains the reason for the message rejection. Additionally, it is easier to search for rejection information in the SMSDEBUG.LOG, as the error information in the log will be preceded by “MessageAccountingReject:”.

2010-06-17:

* SMPP Configuration: Add a scroll bar to the “SMSC Character Set” options list to allow easier selection of different character sets.

* SMS Gateway Accounting Callbacks: Fix “SMSOut” accounting callback to start with the text “Retry Pending” for “Status” when a message delivery attempt fails, but a retry is still pending, allowing temporary errors to be properly distinguished from final error conditions.

* SMS Gateway: Optional fix for segmentation logic to avoid repeating UDH headers when NowSMS is automatically segmenting a long message submitted via SMPP “message_payload” or via HTTP. Repeating UDH headers in all segments can cause problems for some uses, particularly SIM data download. To enable this logic, add RepeatUDHAllSegments=No under the [SMSGW] header of SMSGW.INI.

* SMS Gateway/SMPP Client: When operating in sync mode, if ESME_RTHROTTLED is returned, after waiting for the throttle delay, the same message will be re-attempted up to 5 times.

* SMS Gateway/SMPP Client: The SMPP Throttle error delay is now configurable on a per connection basis. The default throttle error delay is 5 seconds. To set a global throttle error delay that applies to all connections, add SMPPThrottleErrorDelay=## (where ## is a number of seconds) under the [SMSGW] header of SMSGW.INI. To specify a delay that should be used only for a specific connection, add SMPPThrottleErrorDelay=## to the [SMPP - server:port] section for the connection.

* SMS Gateway/SMPP Client: Add configuration option to treat the ESME_RMSGQFUL (receive message queue full) error the same way as a throttling error, subjecting it to the SMPPThrottleErrorDelay pause. This option can be activated for inidividual SMPP connections if desired by adding ThrottleForQFull=Yes under the [SMPP - server:port] section header for a connection.

* SMS Gateway: Additional performance optimisations for user credit balance and quota tracking.

* SMS Gateway: Fix for a message encoding problem when sending long text messages via an outbound SMPP connection with WDP Adaptation enabled if the message contains source and/or destination port addressing.

2010-06-04:

* SMS Gateway/GSM Modem Receive Message: Fix for a problem where the sender phone number was not being interpreted correctly for some messages. For some reason, the problem messages were being received with the sender address type being set to a reserved/unknown value, which was causing NowSMS to mistakenly interpret the sender address as being alphanumeric.

2010-06-02:

* SMS Gateway: Performance optimisations for user credit balance tracking.

2010-06-01:

* MMSC/MM4: When generating MM4_forward.RES acknowledgments include the “X-Mms-Message-ID:” and “X-Mms-Transaction-ID:” headers exactly as they were received. Previously, quote characters were added to these values if they were not present in the received message, because the MM4 specification (3GPP 23.140) defines these headers as requiring quoted-string values. This was causing a problem with an MM4 interconnect to NTT DoCoMo Japan, which is not properly formatting these headers with quoted-string values. In the unlikely event that this change causes a problem with other MM4 interconnects, a configuration setting has been added to force the old behaviour which would always format these values as quoted-string. To enable this old behaviour, edit MMSC.INI and under the [MMSC] header, add ForceMM4QuotedMessageID=Yes.

2010-05-25:

* MMSC: Fix for a corrupt message problem that triggered repeated MMSC restarts and denial of service.

2010-05-24:

* SMS Gateway: Fix for bug effecting the “ReRouteReceived” setting, which allows messages received via an SMSC connection to be redirected for delivery via another SMSC connection. Recent changes to allow accounting callbacks to specify message routing was causing invalid routing information to be recorded for these messages, causing them to be stuck in the queue.

2010-05-20:

* GSM Modem Handling: When routing messages received via a GSM modem to an SMPP client account, if the modem phone number is not available, insert a value of “1″ as the destination address instead of blocking the message from being received by the SMPP client.

2010-05-17:

* SMS Gateway: 2010-05-07 version had a problem with “Stuck messages” if messages were submitted with explicit queue routing (&SMSCRoute=routename), and the setting UseRouteQueues=Yes was not applied.

2010-05-13:

* GSM Modem Handling: Additional checks to stop polling memory locations that don’t exist on unusual modems like the Multitech CDMA modem. (Was not an operational problem, but resulted in a lot of error information in debug logs.)

2010-05-12:

* GSM Modem Handling: Add an additional modem test (AT+CREG?) to check if the modem reports loss of signal. If the loss of signal condition persists, trigger a soft reset of the modem to try to get the modem to reconnect with the operator.

* GSM Modem Handling: Fix for a “CMS ERROR: 340″ issue that could occur with some CDMA modems that emulate GSM modems, where NowSMS would try to use support for GSM Phase 2+, even if it was not enabled in the configuration.

2010-05-07:

* SMS Gateway: Add the capability to define the number of transmitter, receiver and/or transceiver connections to be allocated for a single SMPP connection, without requiring multiple duplicate connections to be defined. In the [SMPP - server:port] section of SMSGW.INI, the following settings are supported: TransmitterCount=## and ReceiverCount=##. TransmitterCount=## defines the number of transmitter connections to be established. If transceiver mode is configured, TransmitterCount specifies the number of transceiver connections to be established. If transceiver mode is not configured, ReceiverCount specifies the number of receiver connections to be established. Note that the number of receiver connections cannot be greater than TransmitterCount.

* SMS Gateway: Performance optimisations for large message queues, especially when there are a large number of outbound SMSC connections. Previously documented UseRouteCache=Yes parameter setting is now enabled by default. In the event of unexpected problems, the new routing logic can be disabled with a setting of UseRouteCache=No under the [SMSGW] header of SMSGW.INI.

* SMS Accounting Callbacks: Add SMPPOptions TLV parameters to the accounting callbacks.

* SMS Accounting Callbacks: Fix for a problem with accounting callbacks if text included “@@”.

* MMSC: Fix problem with automatic MMS version detection that was preventing some MMS clients from recognising that the MMSC supports read receipts, causing clients to send read receipts as standard messages (bug was introduced in early 2009 versions).

* MMSC: Add pre-auth callback for “MMSReadReport” when an MM1 client is submitting a message read receipt. (A pre-auth callback is not necessarily required for this event, however it is being added for consistency, since a pre-auth callback does exist for delivery reports.) Pre-auth delivery report callback also modified to include AccountingExtraHeaders if configured.

* MMSC: Fix for MMSC routing callback not including the “From=” parameter for messages submitted via the web interface.

2010-04-20:

* SMS Gateway: Fix for a routing issue where multiple SMSC connections have the same sender address, where one route has one or more preferred routes, and another route with the same sender address has “Support any outbound message traffic” checked. Messages with a matching sender address should only be routed to the first route if the recipient matches a preferred route, however it was being routed to either route. Note: This only applies to sender based routing.

2010-04-15:

* Accounting Callbacks: Add additional parameter “AcctInfo=” that can be included when submitting a message via HTTP. If included on submission, this parameter will be passed to subsequent accounting callbacks regarding the message.

* MMSC: Fix for MM4 message decoding problem when “Content-Location:” header contains a space character. According to RFC2557, White space characters do not appear to be valid as part of a location name in this header. A change to allow them is being implemented to address a problem where customers are receiving corrupt messages from some Verizon phones.

* SMS Gateway: New performance optimisations for performance problems with large message queues, especially when combined with a large number of outbound SMSC connections. These performance optimisations are only enabled in this version when UseRouteCache=Yes is specfied under the [SMSGW] header of SMSGW.INI.

* Internal: Include additional error checking to detect and automatically repair SQLite databases that are used for receipt tracking.

* Internal: Update SQLite databased (used for message id receipt tracking) to v3.6.23.

2010-03-18:

* SMS Gateway: Fix for 2-way SMS problem on Windows XP systems, where early 2010 versions would have problems sending replies to 2-way SMS messages because of corrupt “SMSCRoute=” information being added to the SMS message.

* SMS Gateway: Add configuration settings to disable user logging and quota management features to add performance for systems that do not need user logs and/or quota tracking. Under the [SMSGW] header of SMSGW.INI, the following settings have been added: DisableUserLog=Yes – This setting disables the creation of user specific log files in the USERS\username directory structure. DisableUserQuota=Yes – This setting disables the tracking of how many messages each user account sends in a day.

2010-03-10:

* SMS Gateway: Fix for delivery receipts message IDs not being tracked if the sender address is alphanumeric containing a ‘ (single quote/apostrphe) character.

* SMS Gateway: Minor performance optimisation for large message queues (could be major for some installations, minor for others).

* WAP Push testing parameters added to meet a particular conformance test which required support for WAP Push SI, SL and CO messages using WBXML version 1.1 and the iso-8859-1 character set. NowSMS defaults to using WBXML version 1.2 and the UTF-8 character set. To set the WBXML version, edit SMSGW.INI and under the [SMSGW] section header, add WAPPushWBXMLVersion=1.1. To specify iso-8859-1 as the WAP Push character set, use WAPPushUseUTF8=No in the [SMSGW] section of SMSGW.INI.

2010-02-10:

* Fix for error message confusion where NowSMS would report an error about the SMPP port already being in use when the port conflict actually involved the SMTP port.

SMPP (Short Message Peer-to-Peer) Protocol is an industry standard protocol that is used for exchanging SMS messages between peer entities.  In SMPP terminology, two types of entities are defined, a Short Message Service Centre (SMSC), and an External Short Messaging Entity (ESME).

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

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

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

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

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

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

One more thing …

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

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

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

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

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