The NowSMS Tech Support Files

Bug Sending Long Binary SMS Messages to Java Apps on Motorola Devices

2009-11-05T16:48:00.004Z

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://blog.nowsms.com/2007/06/long-sms-text-messages-and-160.html.

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://blog.nowsms.com/2007/06/send-sms-to-java-appmidlet.html.

SMS and MMS with the Novatel Merlin XU870 ExpressCard Modem

2009-11-02T13:00:00.000Z

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/documentation/quickstartguide/.

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

Using NowSMS as a WAP Push Proxy Gateway (PPG)

2009-10-29T18:00:00.000Z

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

Even though NowSMS has its own MMSC capability, we do have customers who are using NowSMS as a push proxy gateway for another vendor's MMSC.

In addition to providing PPG support for MMS, NowSMS can be used as a push proxy gateway for other types of push messages, including, but not limited to SyncML DM, SyncML DS, Wireless Village/IMPS, OMA Digital Rights Management, OMA E-Mail Notification (EMN), Service Indication and Service Load.

To post a push message via the PAP interface, perform an HTTP POST to the "web" port configured for the NowSMS web interface (not the MMSC), posting to a URL of "/pap". If user authentication is enabled in NowSMS, user identification can be included as URL parameters (e.g., "/pap?user=username&password=password"), or via an HTTP Basic Authentication "Authorization:" header.

A PAP post is a multipart MIME request, with the first MIME part being the PAP control document that specifies message recipient(s). The second MIME part is the data to be pushed.

An example of a service indication push being sent via PAP is shown below:

-----------------BEGIN EXAMPLE-----------------

POST /pap?user=username&password=password HTTP/1.0

Content-Type: multipart/related; boundary=mime-boundary; type="application/xml"

Content-Length: xxxxx

--mime-boundary

Content-Type: application/xml

--mime-boundary

Content-Type: application/xml

<?xml version="1.0"?>

<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP 2.0//EN" "http://www.wapforum.org/DTD/pap_2.0.dtd"

[<?wap-pap-ver supported-versions="2.0,1.*"?>]>

<pap>

<push-message push-id="9fjeo39jf084@pi.com">

</push-message>

</pap>

--mime-boundary

X-Wap-Application-Id: x-wap-application:wml.ua

Content-Type: text/vnd.wap.si

<?xml version="1.0"?>

<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"

"http://www.wapforum.org/DTD/si.dtd">

<si>

<indication href="http://www.xyz.com/email/123/abc.wml" created="2009-10-25T15:23:15Z"

si-expires="2009-11-03T00:00:00Z">

You have 4 new emails

</indication>

</si>

--mime-boundary--

-----------------END EXAMPLE-----------------

Note that the "/type=user@ppg.operator.com" included in the WAP Push address specification is optional for NowSMS, and will be ignored, as only the relevant destination phone number is parsed from the request.

NowSMS will perform XML to WBXML conversions for WAP push of the following content types:

text/vnd.wap.si
text/vnd.wap.sl
application/vnd.oma.drm.rights+xml
text/vnd.wap.emn+xml (or application/vnd.wap.emn+xml)
text/vnd.wap.co
text/vnd.wap.connectivity-xml

Other types (including non WBXML based encodings such as "application/vnd.wap.mms-message" for MMS or "application/vnd.syncml.ds.notification" for SyncML SAN/DS) must be submitted via the appropriate binary encoding.

NowSMS supports the following text values for "X-Wap-Application-id":

x-wap-application:push.sia
x-wap-application:wml.ua
x-wap-application:wta.ua
x-wap-application:mms.ua
x-wap-application:push.syncml
x-wap-application:loc.ua
x-wap-application:syncml.dm
x-wap-application:drm.ua
x-wap-application:enm.ua
x-wap-application:wv.ua

Other "X-Wap-Application-id" header values must be submitted to NowSMS using their assigned decimal or hexadecimal value rather than the text name. (If using a hexadecimal value, preface the value with "0x" to indicate hexadecimal format.)

Further information on the WAP Push Access Protocol can be found from by downloading the WAP-247-PAP specification from http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html

Note that NowSMS does not support guaranteed delivery or delivery notifications.

NowSMS does not support base64 encoding for PAP content, binary content should be posted as 8-bit data using Content-transport-encoding: binary. We further recommend that the MIME part that includes the binary content have a "Content-Length:" header to avoid the potential of extra bytes (such as blank lines) being interpreted as part of the binary stream.

NowSMS sends WAP Push messages using connection-less WDP (Wireless Datagram Protocol) over SMS. SMSC connection from the NowSMS Push Proxy Gateway can use either SMPP, UCP/EMI or CIMD2. GSM modem connections can also be used as the SMSC connection for smaller test environments.

Special considerations exist for WAP Push in CDMA and CDMA2000 environments, namely the SMSC needs to support WDP Adaptation for SMPP. This is described in more detail at http://www.nowsms.com/support/bulletins/tb-nowsms-010.htm.

Sending SMS from Microsoft Excel

2009-10-26T20:26:00.002Z

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

Read the full post here: http://www.nowsms.com/discus/messages/1/41882.html

The gist of the posting is that you cannot use the Excel HYPERLINK command to do this. It would be logical to build a NowSMS URL to send a message, but the HYPERLINK command connects to the URL twice, resulting in duplicate messages being sent.

As an alternative, Des created a VBScript macro instead. This macro initiates an HTTP connection to NowSMS to send a message, dynamically creating a message based upon cell values in the Excel spreadsheet. I've quoted the details from Des below:

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.

Post any questions or commands in the discussion board posting at http://www.nowsms.com/discus/messages/1/41882.html.

SMS and MMS with the Alcatel One Touch X200 or X060 USB Modem

2009-10-14T09:30:00.001Z

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://blog.nowsms.com/search/label/GSM%20modem

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/documentation/quickstartguide/.

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 alternative modems, please see our other reviews: http://blog.nowsms.com/search/label/GSM%20modem

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

T-Mobile (USA) 3G WebConnect USB Modem - Not for MMS

2009-10-12T09:00:00.001Z

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://blog.nowsms.com/search/label/GSM%20modem.

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

Using NowSMS with Check Point Connectra

2009-10-07T17:07:00.000Z

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

It has come to our attention that the Check Point Connectra unified remote access solution has a security option to send a token via SMS as part of the remote user authentication process.

To facilitate this option, the Check Point Connectra Gateway would be configured to transmit the token via an SMS service provider. While SSL/TLS is available to secure the transmission to the SMS service provider, some end users may not have full confidence in the security mechanisms at the SMS service provider.

An alternative SMS solution is to use the Now SMS/MMS Gateway product (or the entry level NowSMS Lite product) in conjunction with a GSM modem.

The NowSMS server and GSM modem can be installed within the customer network, with appropriate firewall and access controls.

For sending SMS messages, the Check Point Connectra Gateway is configured with an HTTP URL to connect over the local network to the NowSMS server. This HTTP connection is performed each time an SMS message needs to be sent.

The NowSMS server requires a GSM modem with an active SIM card subscription to a mobile operator. To the mobile operator, the GSM modem looks like any other mobile phone. The NowSMS server is able to exchange SMS messages with other mobile phones through the GSM modem.

The configuration of the SMS service provider in the Check Point Connectra Gateway requires the following information:

SMS provider URL – For connecting to a NowSMS Server, we recommend the following setting: http://ip.addr:port/?unused=$APIID&user=$USERNAME&password=$PASSWORD&PhoneNumber=$PHONE&text=$MESSAGE

ip.addr would be the IP address of your NowSMS server installation.

port is the "Port Number for the web interface" configured in NowSMS, which defaults to 8800.

Username – This refers to the "User Name" of a user account created on the NowSMS Server under the "SMS Users" page.

Password – This refers to the "Password" of a user account created on the NowSMS Server.

API ID – This parameter is not relevant to NowSMS can be set as blank, or with the text "unused".

Once these parameters have been properly configured, whenever the Check Point Connectra Gateway needs to send an SMS message, it will connect to the NowSMS server using HTTP, and the SMS message will be transmitted using whatever type of SMSC connection has been configured in NowSMS.

For more information on the Now SMS/MMS Gateway, or NowSMS Lite, please visit http://www.nowsms.com. For additional technical information, visit our discussion forum at http://www.nowsms.com/messages.

SMS and MMS with the Huawei E160 USB Modem

2009-10-05T09:32:00.000Z

The Huawei E160 is an "ok" modem to use with NowSMS to send and receive SMS and MMS messages.

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

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

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

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

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

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

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

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

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

For alternative modems, please see our other reviews: http://blog.nowsms.com/search/label/GSM%20modem

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the Huawei E160, please see the NowSMS Quick Start Guide at http://www.nowsms.com/documentation/quickstartguide/.

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

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

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

Frequencies supported by the Huawei E160:

3G/UMTS/HSDPA - 850Mhz/1900Mhz/2100Mhz (Good for most of the world, plus AT&T USA)

EDGE/GPRS - 850Mhz/900Mhz/1800Mhz/1900Mhz (Global)

HSDPA Max Performance: Download speed - 3.6 Mbps; Upload speed - 384 Kbps (no HSUPA support)

EDGE/GPRS Max Performance: Not specified

NowSMS Support Summary: Supports sending and receiving both SMS and MMS messages. Does not supports "Direct to Modem" ("Default" mode can be used).

SMS Delivery Receipts are supported.

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

Using NowSMS as an SMPP Server for Another Application

2009-10-02T08:55:00.000Z

One of the more unusual features of NowSMS is its ability to operate as an SMPP server. NowSMS can relay messages submitted to its SMPP server to any outbound SMSC connection, which could be one or more GSM modems and/or SMPP, UCP/EMI, CIMD2 or HTTP SMSC connections.

There are a few different reasons why this feature would be used. The simplest scenario is when an end user wants to use a software product that has an existing SMPP interface, but does not want to enter a commercial arrangement with an SMPP based SMS provider. In this scenario, NowSMS acts as a protocol converter between SMPP and other types of SMSC connections.

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

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

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

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

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

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

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

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

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

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

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

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

Ensure that "Enable SMPP Login for this User" is enabled.

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

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

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

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

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

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

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

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

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

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

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

SMPP Error Code Reference

2009-09-28T08:54:00.000Z

Information on how NowSMS handles different SMPP errors can be found at the following link: http://blog.nowsms.com/2007/06/smpp-error-code-handling-in-nowsms.html

This article is a reference for SMPP error codes.

ESME_RINVMSGLEN - 1 - Invalid Message Length (sm_length parameter)

ESME_RINVCMDLEN - 2 - Invalid Command Length (command_length in SMPP PDU)

ESME_RINVCMDID - 3 - Invalid Command ID (command_id in SMPP PDU)

ESME_RINVBNDSTS - 4 - Incorrect BIND status for given command (example: trying to submit a message when bound only as a receiver)

ESME_RALYBND - 5 - ESME already in bound state (example: sending a second bind command during an existing SMPP session)

ESME_RINVPRTFLG - 6 - Invalid Priority Flag (priority_flag parameter)

ESME_RINVREGDLVFLG - 7 - Invalid Regstered Delivery Flag (registered_delivery parameter)

ESME_RSYSERR - 8 - System Error (indicates server problems on the SMPP host)

ESME_RINVSRCADR - 0x0A - Invalid source address (sender/source address is not valid)

ESME_RINVDSTADR - 0x0B - Invalid desintation address (recipient/destination phone number is not valid)

ESME_RINVMSGID - 0x0C - Message ID is invalid (error only relevant to query_sm, replace_sm, cancel_sm commands)

ESME_RBINDFAIL - 0x0D - Bind failed (login/bind failed - invalid login credentials or login restricted by IP address)

ESME_RINVPASWD - 0x0E - Invalid password (login/bind failed)

ESME_RINVSYSID - 0x0F - Invalid System ID (login/bind failed - invalid username / system id)

ESME_RCANCELFAIL - 0x11 - cancel_sm request failed

ESME_RREPLACEFAIL - 0x13 - replace_sm request failed

ESME_RMSGQFUL - 0x14 - Message Queue Full (This can indicate that the SMPP server has too many queued messages and temporarily cannot accept any more messages. It can also indicate that the SMPP server has too many messages pending for the specified recipient and will not accept any more messages for this recipient until it is able to deliver messages that are already in the queue to this recipient.)

ESME_RINVSERTYP - 0x15 - Invalid service_type value

ESME_RINVNUMDESTS - 0x33 - Invalid number_of_dests value in submit_multi request

ESME_RINVDLNAME - 0x34 - Invalid distribution list name in submit_multi request

ESME_RINVDESTFLAG - 0x40 - Invalid dest_flag in submit_multi request

ESME_RINVSUBREP - 0x42 - Invalid 'submit with replace' request (replace_if_present flag set)

ESME_RINVESMCLASS - 0x43 - Invalid esm_class field data

ESME_RCNTSUBDL - 0x44 - Cannot submit to distribution list (submit_multi request)

ESME_RSUBMITFAIL - 0x45 - Submit message failed

ESME_RINVSRCTON - 0x48 - Invalid Source address TON

ESME_RINVSRCNPI - 0x49 - Invalid Source address NPI

ESME_RINVDSTTON - 0x50 - Invalid Destination address TON

ESME_RINVDSTNPI - 0x51 - Invalid Destination address NPI

ESME_RINVSYSTYP - 0x53 - Invalid system_type field

ESME_RINVREPFLAG - 0x54 - Invalid replace_if_present flag

ESME_RINVNUMMSGS - 0x55 - Invalid number_of_messages parameter

ESME_RTHROTTLED - 0x58 - Throttling error (This indicates that you are submitting messages at a rate that is faster than the provider allows)

ESME_RINVSCHED - 0x61 - Invalid schedule_delivery_time parameter

ESME_RINVEXPIRY - 0x62 - Invalid validity_period parameter / Expiry time

ESME_RINVDFTMSGID - 0x63 - Invalid sm_default_msg_id parameter (this error can sometimes occur if the "Default Sender Address" field is blank in NowSMS)

ESME_RX_T_APPN - 0x64 - ESME Receiver Temporary App Error Code

ESME_RX_P_APPN - 0x65 - ESME Receiver Permanent App Error Code (the SMPP provider is rejecting the message due to a policy decision or message filter)

ESME_RX_R_APPN - 0x66 - ESME Receiver Reject Message Error Code (the SMPP provider is rejecting the message due to a policy decision or message filter)

ESME_RQUERYFAIL - 0x67 - query_sm request failed

ESME_RINVOPTPARSTREAM - 0xC0 - Error in the optional TLV parameter encoding

ESME_ROPTPARNOTALLWD - 0xC1 - An optional TLV parameter was specified which is not allowed

ESME_RINVPARLEN - 0xC2 - An optional TLV parameter has an invalid parameter length

ESME_RMISSINGOPTPARAM - 0xC3 - An expected optional TLV parameter is missing

ESME_RINVOPTPARAMVAL - 0xC4 - An optional TLV parameter is encoded with an invalid value

ESME_RDELIVERYFAILURE - 0xFE - Generice Message Delivery failure

ESME_RUNKNOWNERR - 0xFF - An unknown error occurred (indicates server problems on the SMPP host)

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

For additional information, archived versions of the SMPP specification can be found at the following link: http://blog.nowsms.com/2009/03/smpp-34-protocol-specification-archive.html

Now SMS/MMS API Information

2009-09-21T14:00:00.000Z

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.

HTTP Protocol Information

PHP Scripts

Java Examples

Command Line Interface

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

In the future, additional API information may be available at the following link: http://www.nowsms.com/support/api.htm

SMS and MMS with the Option ICON 225 USB Modem

2009-09-21T12:40:00.006Z

The Option ICON 225 is an excellent modem to use with NowSMS to send and receive SMS and MMS messages.

This modem is readily available in many countries, as many mobile operators sell this modem as part of a mobile broadband package. (The modem that we tested was sold by Orange UK, but unlocked versions of this modem are avaialable from multiple web sites.)

If you are using an unlocked version of this modem, do not install the software that is included on the USB drive of the modem, which may be branded for a specific carrier. Instead, download the modem driver software from http://support.option.com.

You may encounter a problem where NowSMS complains that the modem is already in use. The GlobeTrotter software that installs with the modem drivers may try to automatically make a data connection each time Windows is restarted. If this happens, load the GlobeTrotter software by clicking on its icon in the Windows tray (right side of the Windows taskbar, near the date and time display). Open the GlobeTrotter software and press the "More" button, then uncheck "Auto Connect".

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the Option ICON 225, please see the NowSMS Quick Start Guide at http://www.nowsms.com/documentation/quickstartguide/.

Frequencies supported by the Option ICON 225:

3G/UMTS/HSDPA - 2100Mhz (Most of world, not North America)

EDGE/GPRS - 850Mhz/900Mhz/1800Mhz/1900Mhz (Global)

HSDPA Max Performance: Download speed - 3.6 Mbps; Upload speed - 384 kbps (no HSUPA)

UMTS Max Performance: Download speed - 384 Kbps; Upload speed - 384 Kbps

EDGE Max Performance: Download speed - 247 Kbps; Upload speed - 247 Kbps

NowSMS Support Summary: Supports sending and receiving both SMS and MMS messages. Supports "Direct to Modem".

SMS Delivery Receipts are supported.

The Option ICON 225 modem does not support an external antenna (uses internal antenna only).

SMS and MMS with the Sierra Wireless Compass 885 USB Modem

2009-09-17T07:00:00.002Z

The Sierra Wireless Compass 885 USB Modem is a very good modem to use with NowSMS to send and receive SMS and MMS messages.

This modem is readily available in the United States, as AT&T sells it as the "AT&T USBConnect Mercury".

While this modem works extremely well with NowSMS once it is installed, it can be very difficult modem to install. The reason for this is because the primary market for this modem (and other USB modems) is to provide internet connectivity.

If you're looking at using this modem (or a similar modem) with NowSMS, it's probably best not to purchase the modem from the mobile operator with a data plan. When you do this, they are assuming that the primary use of the modem is internet connectivity, and NowSMS will not use the modem for that purpose. Often these data plans don't even have SMS or MMS services enabled.

If you purchase this modem unlocked, it is recommended that you do not use the AT&T branded drivers, but instead use the generic Sierra Wireless drivers. These drivers can be downloaded from http://www.sierrawireless.com/support, specifying "Others" as the "Carrier".

Install these drivers before installing the modem in your PC. When installing the modem, tell Windows that it can find the drivers in the "Program Files\Sierra Wireless Inc\TRU-Install\Drivers" directory.

Unfortunately, when you attempt to add the Sierra Wireless Compass 885 USB Modem to NowSMS, you will most likely encounter the error message "Modem does not properly support command for sending SMS (AT+CMGS)".

Or, with older versions of NowSMS, the modem will add correctly, however any attempt at sending SMS messages will result in the error "ERROR -Modem Response (1): OK".

These errors happen because the driver software for the Sierra Wireless modems actually installs several virtual COM ports for communicating with the modem.

One of these COM ports can be used for sending/receiving SMS messages, while the other COM port can only support data/internet connectivity.

With the 885 modem, multiple virtual COM ports are installed by the Sierra Wireless software. However, a Windows modem driver is installed for only one of these COM ports, so when you select "Sierra Wireless HSPA Modem", you are connecting to a COM port that only supports data/internet connectivity, not SMS connectivity.

To be able to send/receive SMS messages, it is necessary to identify the other COM port.

To identify the COM port, go into the System applet in the Windows Control Panel, and access "Device Manager". In the "Ports (COM & LPT)" section, you will find a port labeled "Sierra Wireless AT Command Port (UMTS)", followed by a COM port number such as COM24.

Once you have identified the COM port number, it is possible to add the modem to NowSMS by referencing the COM port number directly.

However, if you use the COM port directly in NowSMS, you won't be allowed to configure the modem for sending and receiving MMS. It will support SMS only.

The simple way to enable support for sending/receiving MMS is to manually install a Windows Modem driver for this COM port. This can be done through the "Phone & Modem Options" applet in the Windows Control Panel. We recommend that you manually select the modem driver, rather than having Windows detect the modem. For best results, use the "Standard 33600 bps Modem" driver.

After installing this Windows modem driver, configure NowSMS to use the "Standard 33600 bps Modem" to connect with the Sierra Wireless 885, instead of using the direct COM port reference.

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the Sierra Wireless Compass 885, please see the NowSMS Quick Start Guide at http://www.nowsms.com/documentation/quickstartguide/.

Frequencies supported by the Sierra Wireless Compass 885:

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.0 Mbps

EDGE/GPRS Max Performance: Not specified

NowSMS Support Summary: Supports sending and receiving both SMS and MMS messages. Does not supports "Direct to Modem" ("Default" mode can be used).

SMS Delivery Receipts are NOT supported.

The Sierra Wireless Compass 885 modem does have support for connecting an external antenna to enhance the strength of its internal antenna.

SMS and MMS with the Option ICON 322 USB Modem

2009-09-17T06:00:00.003Z

The Option ICON 322 is an excellent modem to use with NowSMS to send and receive SMS and MMS messages.

This modem is readily available in the United States, as AT&T sells it as the "AT&T USBConnect Quicksilver".

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the Option ICON 322, please see the NowSMS Quick Start Guide at http://www.nowsms.com/documentation/quickstartguide/.

Frequencies supported by the Option ICON 322:

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 - 3.6 Mbps; Upload speed - 1.46 Mbps

UMTS Max Performance: Download speed - 384 Kbps; Upload speed - 384 Kbps

EDGE Max Performance: Download speed - 247 Kbps; Upload speed - 247 Kbps

NowSMS Support Summary: Supports sending and receiving both SMS and MMS messages. Supports "Direct to Modem". This is one of the fastest modems that we have seen for sending SMS messages on circuit switched networks, even on 2G/2.5G networks, where speeds of 1 message every 2 to 3 seconds is typical.

SMS Delivery Receipts are supported.

The Option ICON 322 modem does not support an external antenna (uses internal antenna only).

SMS and MMS with the Novatel MC950D USB Modem

2009-09-17T05:00:00.003Z

The Novatel Wireless Ovation MC950D USB Modem is a very good modem to use with NowSMS to send and receive SMS and MMS messages.

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=139&Itemid=305. (If this direct link is broken, navigate from http://www.novatelwireless.com/support/.)

There are no special considerations for using the Novatel MC950D modem with NowSMS.

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the Novatel Wireless Ovation MC950D, please see the NowSMS Quick Start Guide at http://www.nowsms.com/documentation/quickstartguide/.

Frequencies supported by the Novatel Ovation MC950D

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.1 Mbps

SMS and MMS with the SonyEricsson MD300 or MD400 USB Modem

2009-09-17T04:00:00.006Z

The SonyEricsson MD300 USB Modem is a very good modem to use with NowSMS to send and receive SMS and MMS messages.

When attempting to add the MD300 modem to NowSMS, you may encounter the error "Modem does not properly support command for sending SMS (AT+CMGS)".

This is due to a power management feature of the modem. You may notice that there when using the SonyEricsson Wireless Manager, there is a blinking light on the modem. However, the light is not blinking when NowSMS reports this error.

NowSMS versions after 2009.08.14 include support for automatically powering up SonyEricsson modems, which will resolve this problem. If you are using an earlier version of NowSMS, an update can be downloaded at http://www.nowsms.com/download/nowsmsupdate.zip.

For general information on configuring NowSMS to send and receive SMS and MMS messages with a GSM modem, such as the SonyEricsson MD300, please see the NowSMS Quick Start Guide at http://www.nowsms.com/documentation/quickstartguide/.

Frequencies supported by the SonyEricsson MD300:

3G/UMTS/HSDPA - 850Mhz/1900Mhz/2100Mhz (Good for most of the world, plus AT&T USA)

EDGE/GPRS - 850Mhz/900Mhz/1800Mhz/1900Mhz (Global)

HSDPA Max Performance: Download speed - 3.6 Mbps; Upload speed - 384 Kbps (no HSUPA support)

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

NowSMS Support Summary: Supports sending and receiving both SMS and MMS messages. Supports "Direct to Modem" (does not support Phase 2+).

SMS Delivery Receipts are supported, but problems are noted. If a delivery report is received while a message is being sent, the modem will neglect to acknowledge that the current message was sent, resulting in a delayed retry, and most likely a duplicate message.

The SonyEricsson MD400 supports the same frequencies as the MD300, but adds higher speed HSDPA and HSUPA support:

HSPA Max Performance: Download speed - 7.2 Mbps; Upload speed - 2 Mbps

The SonyEricsson MD300 and MD400 modems do not support an external antenna (uses internal antenna only).

Introducing NowWAP 2009

2009-08-11T09:00:00.000+01:00

NowMobile is proud to introduce the latest version of the NowWAP Proxy/Gateway, NowWAP 2009. We'd like to take this opportunity to let you know what is new in NowWAP 2009.

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

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

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

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

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

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

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

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

USSD and NowSMS, revisited

2009-07-31T18:54:00.005+01:00

There seems to be a lot of renewed interest in USSD applications these days.

SMPP is very widely used as an interface into USSD systems, and because of the flexible implementation of SMPP in NowSMS, the 2-way command facility can be a convenient platform for deploying USSD services.

All USSD codes are operator specific. So they are different from SMS short codes where, at least within country, there is interoperability support amongst the operators to allow cross operator short codes.

If you want to deploy a USSD application, then you need to be a mobile operator, or you need to do it through a connection to a mobile operator's USSD gateway. You can't just use a GSM modem. You can't just go to a bulk SMS provider and get a connection.

So, when we get asked questions about USSD support, sometimes it is a technical curiosity question ... people looking for potentially cheaper alternatives to SMS. In those cases, generally, it is not worth pursuing.

When interfacing with USSD, it is important to realise that each vendor's USSD interface can be somewhat different.

Having provided technical support for a number of NowSMS customers implementing USSD services, we've noticed a sort of "de facto" standard for how many USSD SMPP interfaces are implemented.

In general, it is quite difficult to implement a USSD service using simple 2-way SMS commands. It is possible, but it depends on how the USSD system is implemented.

Most USSD systems use an SMPP service_type of "USSD". To set this value in NowSMS, edit SMSGW.INI, and under the [SMPP - host:port] section for the SMPP connection, add ServiceType=USSD.

Many USSD systems also use the ussd_service_op and its_session_info optional SMPP parameters.

The ussd_service_op parameter is used as it is described in the SMPP documentation.

The its_session_info parameter is used to contain a session/transaction id so that the USSD server can maintain the session state of an active USSD session.

To enable NowSMS support for these parameters, edit SMSGW.INI, and create a new section like this:

[SMPPOptions]

ussd_service_op=501,Integer,1

its_session_info=1383,Integer,2

If an [SMPPOptions] section already exists in SMSGW.INI, add the above parameters to that section.

Note that the SMPP specification defines both of these parameters as octet strings, but as they contain binary values, it is easier to work with them in NowSMS by defining them as integer types.

When these parameters are used by a USSD system, the it is generally required that the its_session_info be returned back in any replies.

When simple 2-way SMS is used (e.g., "command returns response text"), NowSMS can be configured to automatically include this parameter in the response by editing SMSGW.INI, and under the [SMSGW] header adding:

2WayReplyCopySMPPOptions=its_session_info

When the above parameter is present in SMSGW.INI, whenever NowSMS processes a 2-way SMS command of the "command returns response text" type, where the its_session_info parameter is set. NowSMS automatically generates the its_session_info in the reply message that is generated.

It is more difficult to work with the ussd_service_op parameter. The mobile originated message will use one ussd_service_op value, and you will be expected to use a different ussd_service_op value in the reply, depending on the type of response that you wish to send. (Some USSD systems may assume that if this is not present, the reply is a simple response that should be delivered and then the session closed.)

For most applications, they will always reply back with the same ussd_service_op value for all messages. In that case, it is possible to edit SMSGW.INI, and under the [SMPP - host:port] section that defines the SMPP connection to the USSD gateway, add DefaultSMPPOptions=ussd_service_op=x ... where x is the value that you want to set for this parameter. NowSMS will then set that parameter value for all messages sent via this particular SMPP connection.

If it is necessary to set different values for this parameter for different messages or message types, or you need to otherwise process either of these parameters in a 2-way command, HTTP based 2-way commands must be used.

NowSMS will automatically append "&SMPPOption_ussd_service_op=x" to the 2-way command URL when the "ussd_service_op" parameter is defined in the [SMPPOptions] section of SMSGW.INI *and* the parameter is present in a received message.

To specify any of these parameters in a reply, the 2-way command must use the "redirect response" technique described at http://www.nowsms.com/support/bulletins/tb-nowsms-003.htm. "&SMPPOption_ussd_service_op=x" can be appended to the URL built to submit the message to NowSMS to specify a value for this option.

So far it has been our experience that a lot of USSD SMPP interfaces use the above techniques. However the SMPP standard does not fully cover USSD. In fact, the its_session_info parameter was actually defined for Korean PCS systems, not as a standard for USSD. Because of this, different vendors have taken different approaches.

We recently worked with a customer who was interfacing with the Halys UltraComp USSD Platform, which uses different techniques for encoding these parameters. You can read about experiences integrating with that platform on the NowSMS Discussion Board at http://www.nowsms.com/discus/messages/1/41585.html.

If you have any questions about USSD, please join us on the NowSMS Discussion Board.

NowSMS 2009 Now Available

2009-07-10T08:33:00.000+01:00

NowSMS 2009 is the fastest performance release of NowSMS to date. While we've added considerable new functionality, we've successfully avoided the bloatware trap.

Effective immediately, licenses supporting up to 400 messages per second are available.

NowSMS 2009 is a free update for users with current upgrade and maintenance agreements. The status of your upgrade and maintenance agreement can be found on the "Serial #" page of your NowSMS installation.

The NowSMS 2009 download can be found at the following link:

http://www.nowsms.com/downloads/

The core performance enhancements are also of interest to other high speed, but not-quite-as-high-speed environments for a variety of reasons.

Requesting delivery receipts for all (or most) messages can put an increased strain on the system, with previous versions of NowSMS peaking at speeds of 150 to 200 messages per second, and sometimes with a queued backlog of receipt processing. Performance is easily doubled in this update, and the queue backlog is no more.
2-way SMS command performance has been optimised, particularly for HTTP based commands, allowing an HTTP based command to easily keep up with burst rates of hundreds of messages per second.
CPU load with large numbers of outbound messaging routes. Historically, the more outbound routes defined to NowSMS, the higher the CPU load, especially if there is a large volume of queued messages waiting for a small number of routes. The routing logic has been dramatically improved to reduce CPU load.
If you use HTTP-based accounting callbacks for billing or accounting, they may be significantly limiting your overall message throughput. The new release uses HTTP keep-alive sockets and optimised logic to improve throughput when accounting callbacks are enabled.

Some of the new features include:

Multimedia Content Push - This is an enhancement to the Multimedia WAP Push functionality support in earlier versions of NowSMS. The new implementation supports dynamic HTML or WML content delivery packaging to support modern phone browsers that do not support WML, such as the iPhone. Sending the content links via standard text messages instead of WAP Push is also supported to make it easier to work with on North American networks, and to work with devices that don't support WAP Push, such as the aforementioned iPhone. More information can be found here:http://blog.nowsms.com/2009/04/sending-multimedia-content-push.html
Enhanced SMS Message Routing Logic - Recipient address masks can now specify addresses to exclude from the selected route, in addition to the existing inclusive logic. Additionally, the SMPP service_type value can be used as a basis for SMS message routing. Some additional preliminary information can be found in the following message thread: http://www.nowsms.com/discus/messages/1/24460.html
Dynamic SMS Message Routing Callbacks - This capability is long overdue! It has been availalble for MMS message routing for some time. Essentially, the existing HTTP accounting callbacks have been extended to allow the callbacks to dynamically specify which outbound route should be used for SMS message routing. Some additional preliminary information can be found in the following mesasge thread:http://www.nowsms.com/discus/messages/1/23919.html
Explicit SMSC Routing available to SMPP Clients - Perhaps not as signicant as the other enhancements, but it is now possible to give SMPP clients connecting to NowSMS as their SMPP server more control over outbound SMSC routing if desired. Some additional preliminary information can be found in the following message thread: http://www.nowsms.com/discus/messages/1/24485.html
Throttling support for outbound MMS routing speed for external MM7, MM4 or EAIF connections.
Enhanced support for the "mailto:" command as used in 2-way commands for routing received SMS messages to e-mail. Additional preliminary information can be found in the following message thread:http://www.nowsms.com/discus/messages/1/24428.html.
More flexibility in controlling message retry behaviour in UCP/EMI and CIMD environments, as described in the following post: http://blog.nowsms.com/2008/10/sms-retry-error-handling-with-ucpemi.html
Delivery receipts are now supported for UCP/EMI and CIMD environments, with NowSMS automatically translating message receipts for those environments into SMPP format to simplify processing.
MMSC/MM4 Enhancements for improved real-world compatibility with more MMS interconnect services.
Improved Modem Handling - Especially recovery and prevention of "hung modem" scenarios.

The above list is just a sampling of a few of the features/capabilities that seemed significant to me as I typed this message. A more complete list of features and enhancements can be found in the readme file, which is posted at http://www.nowsms.com/discus/messages/53/41528.html.

Introducing NowSMS Lite

2009-07-09T20:44:00.002+01:00

The Now SMS/MMS Gateway is one of the most widely used middleware software solutions for SMS, MMS and WAP Push messaging needs. When asked to explain it, we often refer to it as a Swiss Army Knife of mobile messaging protocols.

Since it's introduction in 2002, we've consistently updated NowSMS to support the widest variety of SMS and MMS protocols, following both the latest industry standards, and the real world variations that make you realise how incomplete the standards are.

We're proud to talk about how well the NowSMS product scales from entry level test-lab configurations to production mobile operator environments.

However, with all of the flexibility of the NowSMS product comes a lot of complexity. That complexity is great for the core technical audience of NowSMS, but it is overwhelming for those that are newer to SMS and MMS messaging technologies, or that have less demanding messaging needs.

The NowSMS Lite edition is designed to send and receive SMS and MMS messages using a single GSM (GRPS/EDGE/3G) modem.

The NowSMS Lite Edition allows clients to submit SMS messages to NowSMS for delivery via the GSM modem, using either the HTTP or SMPP protocols. NowSMS Lite also provides examples for submitting SMS messages from Java, PHP and a command line interface.

Received SMS messages can be routed to an application program using either HTTP, SMPP, or a command-line interface.

The NowSMS Lite Edition allows clients to submit MMS messages for delivery via the GSM modem, using either a proprietary HTTP interface that supports both HTTP GET and POST operations, or using the MM7 protocol. MM7 is a SOAP/XML based protocol that operates over HTTP POST. Additionally, NowSMS Lite provides examples for submitting MMS messages from Java, PHP and a command line interface.

Received MMS messages can be routed from NowSMS Lite to an application program using either MM7, an HTTP interface optimised for PHP, or via a file/directory based interface.

A free 30-day trial version of NowSMS Lite is available for download at http://www.nowsms.com/lite/download.

The product manual for NowSMS Lite is available on-line at:

http://www.nowsms.com/lite/documentation

Or to download a copy of the product manual, right click on http://www.nowsms.com/download/nowsmslite.pdf.

As a special introductory offer, NowSMS Lite will be available for £195 (GBP) through September 30, 2009.

SMSGW.INI and MMSC.INI Advanced Parameters

2009-06-30T21:51:00.002+01:00

Below is a link to a document that describes the latest advanced configuration parameters available for NowSMS in the SMSGW.INI and MMSC.INI files:

http://www.nowsms.com/download/NowSMS2009Ini.pdf

MM7 Schemas and MMS Version Number Confusion, revisited

2009-05-22T20:11:00.003Z

Receiving this e-mail about a recent post got me thinking that it might be worth sharing these thoughts here. It's got a little more opinion than other posts, but I think it is interesting for many people who are working with, or trying to work with, MM7.

quote:
Hi,

I read the article, MM7 Schemas and MMS Version Number Confusion, and it answered the difference between mm7 verion and mms version, but I wonder do they have the mapping relationship?
for example: REL-5-MM7-1-2 - 5.3.0 (version is actually 5.5.0, but schema requires 5.3.0) , which standard document define which mms version shall use which schema.

Thanks!

Br,
Tommy

Hi Tommy,

As I read back through it, that blog article is pretty good about defining that table ... defining which schema was introduced in which version of the specification.

The relevant specifications are 3GPP TS 23.140, which defines the MMS protocols. Similarly, 3GPP TS 23.040 defines SMS.

There is no table that is defined by the specifications themselves. You have to review the different versions of the specifications themselves and try to figure out what has changed.

An archive of different versions of MMS can be found here:

http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/

Note: MM1, the over-the-air MMS protocol is only defined in abstract in this specification. It's technical realisation is defined by the OMA (http://www.openmobilealliance.org).

23140-520.zip (3GPP TS 23.140 V5.2.0) is the first version that defines a technical realisation of MM7. However, it's not a true technical realisation, as it only defines MM7 in an abstract fashion ... defining transactions and elements ... but not defining an XML schema or even mandating that the HTTP protocol be used for MM7. (To quote from Section 7.1.13.1, "For example, if HTTP is used as an MM7 transport, many optional authentication mechanisms are available.")

Some MMSC vendors decided to implement MM7 based upon this v5.2.0 specification. This led to MM7 implementations from Ericsson and LogicaCMG that are completely incompatible with the MM7 schema and protocol defined in v5.3.0 of the specification.

23140-530.zip (3GPP TS 23.140 V5.3.0) is the first version that defines MM7 in a true technical realisation. It specifies that SOAP over HTTP POST is used as the transport protocol, and an XML schema is published at: http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0

In NowSMS, we refer to this as schema version REL-5-MM7-1-0.

23140-540.zip (3GPP TS 23.140 V5.4.0) introduces a new schema, http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-1

If you analyse this schema, the only allowed value for the element is 5.3.0, even though this specification is 5.4.0.

23140-550.zip (3GPP TS 23.140 V5.5.0) introduces yet another new schema, http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-2

And is still restricted to 5.3.0.

Needless to say, it is maddening that there are so many different MM7 versions and schemas.

Version number frustration is only part of it!

There are significant changes to types and elements made between different versions of the schema.

Sender address formats are different between different versions of the schema!

"+" is not allowed in a phone number in some versions of the schema!

I realise that it is a lot of work to produce such a large specification ... and it's easy to pick faults (in this case, easier than most).

The reality is that different MMSC vendors have implemented support for different versions of the 3GPP MMS specification. A particular MMSC may only support 1 or 2 versions.

In some cases, most things may work when using a schema that is not supported by a particular in MMSC ... but you encounter weird problems.

For example, one of the issues we encountered recently was a missing/blank sender address when submitting messages via a Huawei MMSC (http://www.nowsms.com/discus/messages/485/24992.html).

The Huawei MMSC only truly understands the REL-5-MM7-1-0 schema from 5.3.0.

Other MMSCs use REL-5-MM7-1-2 as a baseline spec. And they'll reject messages because of invalid sender if you try to use REL-5-MM7-1-0 formatting.

In that case, you need to use the REL-5-MM7-1-2 schema, and specify 5.3.0 ... even though the schema was actually defined in version 5.5.0.

Bottom line ...

MM7 is more difficult than it should be.

In NowSMS, we implement the proprietary MM7 protocols, as defined by Ericsson and LogicaCMG, which preceded 3GPP TS 23.140 v5.3.0.

And we implement v5.3.0 through v6.13.0, and the relevant schemas.

However, we used to allow the MM7 Version number and MM7 Schema values to be configured separately. In newer releases, we only allow the configuration of MM7 Version Numbers that are allowed in the selected MM7 Schema.

That makes it a little less confusing when configuring an MM7 connection in NowSMS.

However, you still really need to know which MMS Schema version is supported by your provider in order to avoid confusion. Sometimes they only tell you the version number, and you need to correlate that to the schema. As you can see, this is really confusing if they are using the REL-5-MM7-1-2 schema (which is a good baseline schema, because it finally stablised some confusing aspects of earlier schemas) ... because the schema requires a version specifier of 5.3.0, even though this schema didn't actually exist until 5.5.0.

Sigh ...

At least we can deal with the schema differences in NowSMS. But there's no way to do version discovery when initiating an MM7 connection ... and that would have simplified a lot of these problems!

Protocol designers should always have a way of dealing with version discovery and/or specify ways of dealing with forward/backward compatibility.

The OMA MMS specifications that define the technical realisation of MM1 (over the air MMS) are actually quite good, and well thought out in this regard.

Needless to say, I've got some strong opinions on this subject ...

Got a comment or question, here's the thread on our discussion board: http://www.nowsms.com/discus/messages/485/25210.html

-bn

MMSC Accounting Callbacks for Billing and Charging

2009-05-07T14:54:00.004Z

MMSC accounting callbacks provide an interface between the NowSMS MMSC and external billing and charging systems.

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

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

MMSAccountingURL=http://server/path

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

For example:

http://server/path?PreAuth=Yes&Type=MMSSend&From=%2B449999999999&To=%2B447777777777&MsgCount=1

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

Most of the accounting callbacks are informational only, and exist to record charging information after the MMSC has processed a transaction.

However, there are also pre-authorisation callbacks which occur before the MMSC processes a transaction. These pre-authorisation callbacks exist to allow the customer billing system to decide whether or not the transaction should be allowed. In this scenario, the callback could check available credit and reject an MMS message transaction before it is accepted by the MMSC.

The following accounting callbacks are supported by the MMSC:

MMSSend PreAuth Callback

This callback is executed when an MMS subscriber, Value Added Service Provider (VASP) or MMSC interconnect partner, 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. A “PreAuth” request to send a message will also be blocked if the HTTP response content includes the text “PreAuth=Deny”.

The following parameter variables may be set for the MMSSend pre-authorisation request:

PreAuth=Yes

The presence of this parameter indicates that this callback is a pre-authorisation request.

Type=MMSSend

The transaction type is MMSSend, indicating that a request is being made to send an MMS message.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber that is sending the message. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber (may be a comma delimited list with multiple recipients)

This parameter contains one or more recipient phone numbers. If more than one phone number is present, this will be a comma delimited list of recipient phone numbers. (Note that URL escaping rules require the "," symbol to be encoded as "%2C".)

VASPIN=MmscVaspName

This parameter is present if the message is arriving from a Value Added Service Provider or MMSC interconnect partner. The value of this parameter refers to the account name as defined in the "MMSC VASP" list.

Note that some versions of NowSMS may preface the MmscVaspName with the text "VASP:".

VASP=MmscOutboundRoute (may be a comma delimited list if multiple recipients)

This parameter is present if the MMSC has determined that the message must be routed via an external route for delivery. The value of this parameter refers to the account name as defined in the "MMSC Routing" list.

If the message is being sent to multiple recipients, this field may contain a comma delimited list of routes with a route listed for each recipient. If there is a mix of local and remote recipients, local recipients will have a blank entry within the comma delimited list of routes.

MsgCount=####

This parameter specifies the number of recipients for this MMS message transaction.

(Note that the MMSSend PreAuth callback is issued only once if an MMS message is being sent to multiple recipients. The MMSSend Charging callback, which records billing and charging information after the MMSC has accepted the message, issues a separate callback for each recipient.)

Size=####

This parameter specifies the size of the MMS message in bytes.

Note that the MMS message size refers to the size of the data using the encoding of the protocol through which the message is being received (e.g., MM1, MM4, MM7). The actual size of the delivered MMS message may be different because of conversion between these protocols, and/or MMS header manipulation.

Also note that this parameter may not be present for all protocols. In particular, this parameter is not present for messages received via the MM4 (MMSC interconnect) protocol.

MMSSend Charging Callback

This callback is executed when an MMS subscriber, Value Added Service Provider (VASP) or MMSC interconnect partner, has submitted a message to the MMSC, and the MMSC has accepted the message for further processing.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSSend Charging Callback:

Type=MMSSend

The transaction type is MMSSend, indicating that an MMS message has been submitted.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber that is sending the message. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber

This parameter contains a single recipient phone number. If the original message was submitted to more than one recipient, a separate charging callback will occur for each recipient.

VASPIN=MmscVaspName

This parameter is present if the message arrived from a Value Added Service Provider or MMSC interconnect partner. The value of this parameter refers to the account name as defined in the "MMSC VASP" list.

Note that some versions of NowSMS may preface the MmscVaspName with the text "VASP:".

VASP=MmscOutboundRoute

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MessageID=assignedMessageID

This parameter records the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

Note that MMS message size may differ based upon the encoding protocol (e.g., MM1, MM4, MM7). The actual size of the delivered MMS message may be different because of conversion between these protocols, and/or MMS header manipulation.

MMSRetrieve Accounting Callback

This callback is executed when an MMS subscriber connects to the MMSC to retrieve the content of an MMS message.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSRetrieve Accounting Callback:

Type=MMSRetrieve

The transaction type is MMSRetrieve, indicating that an MMS subscriber has connected to the MMSC to retrieve the content of an MMS message.

From=SenderPhoneNumber (or EMailAddress)

This parameter contains the phone number or e-mail address of the message sender. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber

This parameter contains the recipient phone number that is retrieving this MMS message.

MessageID=assignedMessageID

This parameter contains the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

MMSOut Accounting Callback

This callback is executed when an MMS message is routed to an external route (VASP or MMSC interconnect) defined in the "MMSC Routing" list.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSOut Accounting Callback:

Type=MMSOut

The transaction type is MMSOut, indicating that an MMS message has been routed to an external route.

From=SenderPhoneNumber (or EMailAddress)

This parameter contains the phone number or e-mail address of the message sender. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber

This parameter contains the recipient phone number for the MMS message.

MessageID=assignedMessageID

This parameter contains the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

VASP=MmscOutboundRoute

This parameter specifies the MMSC outbound route via which the MMS message was routed.

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSOutFailed Accounting Callback

This callback is executed when an attempt is made to route an MMS message to an external route (VASP or MMSC interconnect) defined in the "MMSC Routing" list, but the attempt fails.

Information about the failure is not currently provided by this callback, but can be found in the MMSC-yyyymmdd.LOG file.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSOutFailed Accounting Callback:

Type=MMSOutFailed

The transaction type is MMSOutFailed, indicating that an attempt was made to route an MMS message to an external route, but the attempt failed.

From=SenderPhoneNumber (or EMailAddress)

This parameter contains the phone number or e-mail address of the message sender. Note that URL escaping rules require the "+" symbol to be encoded as "%2B".

To=RecipientPhoneNumber

This parameter contains the recipient phone number for the MMS message.

MessageID=assignedMessageID

This parameter contains the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

VASP=MmscOutboundRoute

This parameter specifies the MMSC outbound route via which the MMS message was routed.

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSDeliveryReport PreAuth Callback

This callback is executed when a Value Added Service Provider (VASP) or MMSC interconnect partner is requesting to send a delivery report. This callback is also generated when the MMSC wants to generate a delivery a report on behalf of a local subscriber.

This is a “pre-authorisation” request, and does not mean that the delivery report 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. A “PreAuth” request to send a message will also be blocked if the HTTP response content includes the text “PreAuth=Deny”.

The following parameter variables may be set for the MMSDeliveryReport pre-authorisation request:

PreAuth=Yes

The presence of this parameter indicates that this callback is a pre-authorisation request.

Type=MMSDeliveryReport

The transaction type is MMSDeliveryReport, indicating that a request is being made to send an MMS delivery report.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber for which the delivery report is being generated (i.e., the original recipient of the message).

To=RecipientPhoneNumber

This parameter contains the phone number to which this delivery report is being sent (i.e., the original sender of the message).

VASP=MmscOutboundRoute

This parameter is present if the MMSC has determined that the delivery report must be routed via an external route for delivery. The value of this parameter refers to the account name as defined in the "MMSC Routing" list.

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSDeliveryReport Charging Callback

This callback is executed when a delivery report is being routed by the MMSC.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSDeliveryReport charging callback:

Type=MMSDeliveryReport

The transaction type is MMSDeliveryReport, indicating that an MMS Delivery Report has been generated.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber for which the delivery report has been generated (i.e., the original recipient of the message).

To=RecipientPhoneNumber

This parameter contains the phone number to which this delivery report is being sent (i.e., the original sender of the message).

VASP=MmscOutboundRoute

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSReadReport PreAuth Callback

This callback is executed when a MMS subscriber, Value Added Service Provider (VASP) or MMSC interconnect partner is requesting to send a read report (a.k.a., message read receipt).

This is a “pre-authorisation” request, and does not mean that the read report 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. A “PreAuth” request to send a message will also be blocked if the HTTP response content includes the text “PreAuth=Deny”.

The following parameter variables may be set for the MMSReadReport pre-authorisation request:

PreAuth=Yes

The presence of this parameter indicates that this callback is a pre-authorisation request.

Type=MMSReadReport

The transaction type is MMSReadReport, indicating that a request is being made to send an MMS read report.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber for which the read report is being generated (i.e., the original recipient of the message).

To=RecipientPhoneNumber

This parameter contains the phone number to which this read report is being sent (i.e., the original sender of the message).

VASP=MmscOutboundRoute

This parameter is present if the MMSC has determined that the read report must be routed via an external route for delivery. The value of this parameter refers to the account name as defined in the "MMSC Routing" list.

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSReadReport Charging Callback

This callback is executed when a read report is being routed by the MMSC.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSReadReport charging callback:

Type=MMSReadReport

The transaction type is MMSReadReport, indicating that an MMS Read Report has been generated.

From=SenderPhoneNumber

This parameter contains the phone number of the subscriber for which the read report has been generated (i.e., the original recipient of the message).

To=RecipientPhoneNumber

This parameter contains the phone number to which this read report is being sent (i.e., the original sender of the message).

VASP=MmscOutboundRoute

Note that some versions of NowSMS may preface the MmscOutboundRoute with the text "VASP:".

MMSEMail PreAuth Callback

This callback is executed when an e-mail message has arrived via SMTP, specifying an MMS recipient.

The following parameter variables may be set for the MMSEMail pre-authorisation request:

PreAuth=Yes

The presence of this parameter indicates that this callback is a pre-authorisation request.

Type=MMSEMail

The transaction type is MMSEMail, indicating that an SMTP request is being made to deliver an MMS message to a subscriber.

From=EMailAddress

This parameter contains the e-mail address of the SMTP message sender.

To=RecipientPhoneNumber

This parameter contains a single recipient phone number.

MsgCount=1

This parameter is always 1 in current versions of NowSMS.

MMSEMail Charging Callback

This callback is executed when an SMTP message has been accepted for routing to an MMS recipient.

NowSMS will ignore any HTTP response returned by the callback, however we recommend returning an "HTTP 200 OK" response for future compatibility reasons.

The following parameter variables may be set for the MMSEMail Charging Callback:

Type=MMSEMail

The transaction type is MMSEMail, indicating that an SMTP message has been accepted for routing to an MMS recipient.

From=EMailAddress

This parameter contains the e-mail address of the SMTP message sender.

To=RecipientPhoneNumber

This parameter contains a single recipient phone number. If the original message was submitted to more than one recipient, a separate charging callback will occur for each recipient.

MessageID=assignedMessageID

This parameter records the MMS message ID assigned by MMSC. Note that if the message was sent to multiple recipients, each recipient instance shares the same message ID.

Size=####

This parameter specifies the size of the MMS message in bytes.

Missing Text Parts from MMS Messages

2009-04-07T08:26:00.000Z

A recent tech support incident where users were receiving MMS messages with missing text parts of the MMS content had us rather confused.

The customer was using NowSMS as an MMSC, and encountered two devices, the Motorola RAZR V8 and ROKR Z6, which were unable to receive any text content within an MMS message.

As a first step of troubleshooting, we recommended that the customer disable "content adaptation" by the MMSC to determine if the problem was related to content adaptation. (This setting is labeled "Enable Dynamic Image + Audio Conversion" in the MMSC configuration.)

The problem did go away with content adaptation disabled. However, disabling this support was not considered to be a permanent solution for the customer.

Upon further investigation, it was determined that the content adaptation problem was caused by errors in the User Agent Profiles (UAProf files) published by Motorola for these devices. The NowSMS MMSC consults these profiles to determine what content types are supported by the MMS client in the receiving handset. The profiles for these devices included a list of content types supported by the MMS client, but did not include plain text (text/plain) as one of the supported content types.

The NowSMS MMSC caches UAProf files in the UAPROF subdirectory of the NowSMS installation. The user was able to manually edit the motorazrv8.rdf and motorokrz6.rdf files in this directory to add support for the content typle "text/plain".

The supported MMS content types are listed in the "MmsCcppAccept" section of the UAProf file. Simply adding <rdf:li>text/plain</rdf:li> within this section of the file is all that is necessary to add support for the "text/plain" content type.

Future versions of the NowSMS MMSC will always assume that "text/plain" is a supported content type within MMS messages, even if there is an error in the UAProf file published by the handset manufacturer.

Sending Multimedia Content Push Messages with NowSMS

2009-04-02T07:15:00.000Z

One of the ways that NowSMS can be used for multimedia content delivery is a service that we refer to as Multimedia Content Push (also referred to as Multimedia WAP Push).

When you send a Multimedia WAP Push message with NowSMS, you post all of the message content (e.g., images, video, text, applet) to the NowSMS server. NowSMS packages the content and dynamically generates a URL on the NowSMS server. A WAP Push message is then sent which includes a link to the content.

To send a Multimedia WAP Push message via NowSMS, the same APIs are used as for sending an MMS message, with a special flag set to indicate that the message should be sent out as a Multimedia WAP Push instead of as an MMS message. The subject of the message is used as the text in the WAP Push, and the remainder of the content is packaged into the dynamically generated URL that accompanies the WAP Push message.

NowSMS 2009 also supports a concept of Multimedia Content Push where the push is sent via a text SMS instead of using WAP Push. The concept is similar to Multimedia WAP Push, except that the message that is sent to the recipient is a standard text message.

This alternative is useful in environments where WAP Push is not supported (such as environments where there is a mix of GSM and CDMA technologies), or where binary messaging required by WAP Push is more expensive than standard text messaging. It is also useful for delivering content to devices that do not support WAP Push, such as the Apple iPhone.

The article will explain how the Send MMS APIs for NowSMS are adapted to support Multimedia Content Push.

The APIs for sending MMS messages are described in the following link:

http://blog.nowsms.com/2009/02/sending-mms-messages-with-nowsms.html

PHP:

Follow the example described at http://blog.nowsms.com/2008/11/nowsms-php-example-send-mms-message.html

To send a Multimedia Content Message using WAP Push, add this line before calling MmsSend:

$mmsMessage = MmsAddField ($mmsMessage, "MMSWAPPush", "Yes");

To send a Multimedia Content Message using Text SMS, add this line before calling MmsSend:

$mmsMessage = MmsAddField ($mmsMessage, "SMSWAPPush", "Yes");

Java:

Follow the example described at http://blog.nowsms.com/2009/02/nowsms-java-example-send-mms-message.html, but include the following additional parameter setting when building the MMS message to send the message via WAP Push:

mms.addparameter ("MMSWAPPush", "Yes");

Or this parameter setting when building the MMS message to send the message via text SMS:

mms.addparameter ("SMSWAPPush", "Yes");

Command Line Interface:

Follow the example described at http://blog.nowsms.com/2007/07/sending-mms-from-command-line.html, but include the following additional parameter in your command line to send the message via WAP Push:

MMSWAPPush=Yes

Or include this additional parameter to send the message as a URL link via text SMS:

SMSWAPPush=Yes

NowSMS Proprietary URL Submission

Follow the example described at http://blog.nowsms.com/2009/02/sending-mms-messages-with-nowsms.html.

Include the following additional variable setting to send the message via WAP Push:

MMSWAPPush=Yes

Or include this additional variable setting to send the message as a URL link via text SMS:

SMSWAPPush=Yes

This additional variable setting can be included in the URL (e.g., &MMSWAPPush=Yes), or it can be included as a variable setting in part of the multipart/form-data.

MM7

Follow the MM7 example described at http://blog.nowsms.com/2009/02/sending-mms-messages-with-nowsms.html.

Append "/TYPE=WAPP" to the recipient phone number to send via WAP Push or "/TYPE=SMSP" to send as a URL link via text SMS.

MM4/SMTP

Follow the MM4 example described at http://blog.nowsms.com/2009/02/sending-mms-messages-with-nowsms.html.

Append "/TYPE=WAPP" to the recipient phone number to send via WAP Push or "/TYPE=SMSP" to send as a URL link via text SMS.

MM1

Multimedia Content Push is not supported via the MM1 Interface, unless the default outbound route for MMS messages is to use "Multimedia WAP Push" ("WAP Push with Web Link") or "SMS with Web Link (Direct)". In this case, MMS messages will be automatically converted to the format specified by the outbound route.

EAIF

Multimedia Content Push is not supported via the EAIF Interface, unless the default outbound route for MMS messages is to use "Multimedia WAP Push" ("WAP Push with Web Link") or "SMS with Web Link (Direct)". In this case, MMS messages will be automatically converted to the format specified by the outbound route.