Small Image Size in Received MMS

A recent posting on our disucssion board got me thinking. The question was asking about how when the customer receives inbound MMS messages via a modem, the images are being scaled down to a thumbnail size.

I don't have a clear-cut answer on how to resolve the situation, because it tends to be a mobile operator specific issue. But I thought my explanation of why it would happen, and how you can configure NowSMS to identify itself as a particular phone model when sending or receiving an MMS message via an operator MMSC might be interesting to some.

I'll go ahead and repost the question and my response here. For more discussion, visit the original posting at: http://www.nowsms.com/discus/messages/485/21779.html

Question:

We have developed an application that uses NOWSMS to retrieve MMS images sent to a mobile cell phone number. We have a GPRS MultiTech modem attached via USB to download the images from the carriers system. The images are coming into the NOWSMS system and being delivered into the MMS-IN folder as they should.

The issue we have is the size of the images. Something is scaling the images down to 160 x 120..I really need to get a larger resolution image. The camera phone is certainly taking a larger image...something is scaling the image down.

Thoughts...suggestions...ideas?

Response:

This behaviour tends to be very much carrier specific, so unfortunately I can't give you a one size fits all answer.

But I can explain what is happening, and give you some technical information that may help you find a solution.

What is happening is that your operator's MMSC is performing content adaptation before delivering the message to your device. What that means is that the MMSC is making changes to the content to "better" adapt it to the receiving device.

At least that is the theory behind it ... different devices have different capabilities ... different screen sizes ... different limits on the maximum image or message size that they can handle.
So in theory, the MMSC is performing a service, and scaling down the image so that it is usable when you receive it.

The reality, however, is that the content adaptation performed by most operator MMSCs is poor ... and ends up diminishing the user experience.

In fact, when I talk to friends of mine that don't work in the mobile phone industry, this seems to be one of their biggest complaints about picture messaging. They take a picture, send it to a friend's phone ... the receiving friend goes to copy the picture to their computer and all they've got is a thumbnail. (Remember that promotion in Switzerland where you could send an MMS from your phone to have it entered into a voting contest for being made into a postage stamp? My thinking is that particular idea started off as a joke, because what else is a 160x120 picture image good for anyway? And if you think I'm kidding, see http://www.swisspost.ch/en/index/uk_mm05_mms_marke.htm?viewId=22980.)

We all know that camera phone picture quality is relatively poor (but improving), but arbitrarily scaling pictures down to 160x120 makes the situation worse.

So ... in a situation like this, the only solution is to try to figure out how to bypass or alter the mobile operator MMSC content adaptation.

Usually, if an image is being scaled down to 160x120, this is what you'd call a "lowest common denominator" size ... that is to say, the smallest image size that is required to be supported by a device that supports MMS.

If the MMSC is scaling down images to the "lowest common denominator", then this usually means that the MMSC does not know what type of device is on the receiving end, so it is assuming that it is the most limited type of device.

In this case, with the receiving device being a modem, it does kind of make sense that the operator MMSC does not know what type of device is on the receiving end.

So how does the operator MMSC know what type of device you are using?

Well, hopefully they are using a solution that is somewhat dynamic (as opposed to a database that records your phone type when you originally sign up for service).

When a device connects to an MMSC, typically the device will transmit some information to the MMSC to indicate the device type.

The device actually communicates with the MMSC using HTTP (or WAP protocols that are logically equivalent), and the device uses HTTP headers to identify the device type.

There are typically two headers that are used to communicate the device type, the "User-Agent" and "Profile" (or "X-WAP-Profile") headers.

The "User-Agent" header is a free-format text string that identifies the device and potentially its firmware version.

The "Profile" (or "X-WAP-Profile") header contains a URL pointer to a UAProf (User Agent Profile) document that is published by the device manufacturer which provides more details about the capabilities and characteristics of the device. (This document uses an XML format defined by the Open Mobile Alliance.)

Here are the "User-Agent" and "Profile" strings used by a few current day devices ...

Motorola KRZR:

User-Agent:MOT-K1/08.22.07R MIB/BER2.2 Profile/MIDP-2.0 Configuration/CLDC-1.1 EGE/1.0
Profile: "http://motorola.handango.com/phoneconfig/k1/Profile/k1.rdf"

Blackberry 8800:

User-Agent: BlackBerry8800/4.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/100
Profile: http://www.blackberry.net/go/mobile/profiles/uaprof/8800/4.2.1.rdf

Nokia N95:

User-Agent: NokiaN95/11.0.026; Series60/3.1 Profile/MIDP-2.0 Configuration/CLDC-1.1
Profile: "http://nds1.nds.nokia.com/uaprof/NN95-1r100.xml"

So how do you convince your mobile operator that your modem is some other type of device?

In a default configuration, NowSMS does not send either of these headers when connecting to an operator MMSC to send or receive MMS messages.

However, in the MMSC.INI file, under the [MMSC] header, you can add the following settings:

HeaderUserAgent=
HeaderProfile=

For example, to pretend that you're an N95:

HeaderUserAgent=NokiaN95/11.0.026; Series60/3.1 Profile/MIDP-2.0 Configuration/CLDC-1.1
HeaderProfile="http://nds1.nds.nokia.com/uaprof/NN95-1r100.xml"

(Note ... the quotes around the Profile URL are not strictly required, I just notice that the actual N95 does include them.)

Whatever values you specify here, NowSMS will add a User-Agent and/or Profile header with the specified values when connecting to the operator MMSC.

Unfortunately, in situations like this, it can be a real trial-and-error experience to figure out what values make a difference.

Note that some MMSCs may only pick up dynamic changes to your configuration when you send a message, not when you receive one. Others may pick up the change when you receive a message, but update their internal information for the next time that someone sends you a message. It is also possible that it may take several minutes for the MMSC to update its internal database after you try a different setting.

So whenever you change this setting, try having the modem send an MMS message to itself ... wait a couple of minutes ... try again ... wait ... then try again a third time to see if anything has changed.

Based upon real world experience, what we have noticed so far is that many MMSCs seem to be more interested in "User-Agent" headers than "Profile" headers. This is quite puzzling to us, because in our MMSC implementation, we rely on the "Profile" header, as it contains much more important information, and does not require that the MMSC be manually configured with information about every single device. (If the MMSC uses User-Agent profiles, then every time the operator adds a new device, someone needs to update a configuration at the MMSC to detail characteristics about that device.)

Because User-Agent profile information seems to be used frequently, we have observed that some operators only have their MMSC provisioned with information about phones that the operator actually sells through their official channels.

I can remember incidents at Telstra in Australia and Rogers in Canada where users experimented with different User-Agent strings for different devices that the operator sold until they could find one that met their needs.

In these cases, it may help if you have multiple devices from the operator where you can try sending MMS messages to the different phones. See what size each phone actually receives ... then you can try to track down the User-Agent and Profile strings relevant for the device.
Like I said, I wish I could give you a one size fits all answer ... but this particular issue does seem to vary significantly between mobile operators.

-bn

Send an MMS to a Java app/MIDlet

In the last post, I talked about sending SMS messages to a Java MIDlet running on a phone by using SMS port addressing. This time I want to explain how to send an MMS message to a Java MIDlet running on a phone, using MMS application ID addressing.

SMS port addressing has been part of SMS, as defined by the ETSI GSM 03.40 specifciation, since at least 1998. So when the Java Community defined their Wireless Messaging API in JSR-120, it made sense to use SMS port addressing as a basis for routing SMS messages to specific applications.

When the MMS protocol was originally defined, there were no considerations made for application or port addressing.

But the Java Community clearly saw a need to be able to have MMS messages delivered to MIDlets, as is possible with SMS messages.

JSR-205 defined extensions to the MMS headers that would support application ID addressing. Specifically they defined additional parameters for the "Content-Type:" header of the MMS message which could indication source (reply) and destination application identifiers.

For example:

Content-Type: application/vnd.wap.multipart.related;
 start=<smil>; type=application/smil;
 Application-ID=destinationApp;
 Reply-To-Application-ID=sourceApp

Meanwhile, the need for application ID addressing was also communicated back to the 3GPP and the Open Mobile Alliance, who are responsible for the actual MMS specifications. But the process of updating these MMS specifications can sometimes be slow. 3GPP introduced Applic-ID headers in TS 23.140 v6.7.0. The Open Mobile Alliance introduced Applic-ID headers in v1.3 of the MMS specification.

The application id (Applic-ID) headers introduced by the 3GPP and OMA are completely different from the application ID addressing extensions defined by JSR-205. This is unfortunate, as it will likely generate considerable confusion and interoperability concerns.

However, in fairness to all parties involved, there are advantages and disadvantages of both definitions. The JSR-205 application ID addressing extensions can be safely implemented on top of any version of MMS, including MMS v1.0, v1.1, v1.2 and v1.3. They do not require an implemenation of a completely new version of the MMS protocol specification.

But, the JSR-205 application ID addressing extensions, while effective, could only support sending and replying to messages. They could not support delivery reports and read reply reports. When the 3GPP and OMA got around to adding application ID addressing support to the MMS protocol, they could not simply adopt the JSR-205 approach, as they likely believed that the inability to support delivery reports and read reply reports was too severe a limitation.

With the full release of NowSMS 2007, we have added support for MMS application ID addressing, implementing support for both JSR-205 and MMS v1.3 (as well as the updated 3GPP TS 23.140 specification).

It is possible to submit an MMS message to NowSMS that includes application ID addressing using any of the following methods:

1.) When sending an MMS message from the NowSMS web form, it is possible to specify the reply (source) and recipient application IDs by making them part of the corresponding sender or recipient phone number. (For example: +44777777777:applicationID)

NowSMS will parse the phone numbers and generate the appropriate JSR-205 and MMS v1.3 headers.

The "phonenumber:applicationID" format is avaialble only for MMS messages being posted via the web interface, or the NowSMS proprietary URL submission format.

2.) When submitting via MM1, it is necessary to use the MMS v1.3 defined "X-Mms-Applic-ID" and "X-Mms-Reply-Applic-ID" binary headers, and/or the "Content-Type" parameters defined by JSR-205.

For example (the following are text examples representations of the binary headers, such as the text headers that would be passed to MMSCOMP):

Message-type: m-send-req
Transaction-id: 501B3E2C
MMS-version: 1.3
From: 5678/TYPE=PLMN
Date: Tue, 19 Jun 2007 18:12:16 GMT
Delivery-report: No
Message-class: Personal
Message-id: 20070619/19/501B3E2C@bigkahuna
Message-size: 634
Priority: normal
Read-reply: No
Subject: MM1 Application ID Test
To: +99999999999/TYPE=PLMN
X-Mms-Applic-ID: destinationApp
X-Mms-Reply-Applic-ID: sourceApp
Content-type: application/vnd.wap.multipart.related;
 start=<4620d4c5.smil>;
 type=application/smil;
 Application-ID=destinationApp;
 Reply-To-Application-ID=sourceApp

Note: When submitting a message via MM1, it is important to note that the JSR-205 "Content-Type" parameters are applied as part fo the binary MMS message headers.

The example above shows a text representation of the MMS message headers. An actual over-the-air MMS message would have these headers encoded in a binary MMS Encapsulation format.

When this binary MMS message is posted to the MMSC, it is done so using HTTP POST, specifying a "Content-Type:" of "application/vnd.wap.mms-message" for the binary MMS message payload of the HTTP POST. The JSR-205 "Content-Type" parameters are encoded inside of the binary MMS message.

Note: If MMSCOMP sees either the JSR-205 "Content-Type" parameters or the "X-Mms-Applic-ID"/"X-Mms-Reply-Applic-ID" headers, it will automatically encode the binary MMS message with application ID values for both headers. However, if the MMSC receives an MM1 submission with just one type of application ID parameters set, the MMSC will forward the resulting message with only that type of application ID parameter set.

3.) When submitting via MM4, use the "X-Mms-Applic-ID" and "X-Mms-Reply-Applic-ID" text headers defined by 3GPP TS 23.140, and/or the "Content-Type" parameters defined by JSR-205. (If NowSMS detects the Application ID parameters being set by either approach, it will automatically apply the Application ID values using both formats in the resulting MMS message.)

For example:

X-Mms-3GPP-MMS-Version: 6.7.0
X-Mms-Message-Type: MM4_forward.REQ
X-Mms-Transaction-ID: "20070619.14.28C55CD2-p99999999999"
X-Mms-Message-ID: "20070619.14.28C55CD2@bigkahuna"
X-Mms-Ack-Request: No
X-Mms-Originator-System: system-user@bigkahuna
Message-ID: <20070619.14.28C55CD2@bigkahuna>
Date: Tue, 19 Jun 2007 14:12:16 -0400
Sender: 5678/TYPE=PLMN@bigkahuna
From: 5678/TYPE=PLMN
To: +99999999999/TYPE=PLMN
X-Mms-Priority: Normal
X-Mms-Delivery-Report: No
X-Mms-Read-Reply: No
X-Mms-Applic-ID: destinationApp
X-Mms-Reply-Applic-ID: sourceApp
Subject: MM4 Application ID Test
Content-Type: multipart/related;
 start="<4620D4C5.smil>"; type="application/smil";
 Application-ID=destinationApp;
 Reply-To-Application-ID=sourceApp;
 boundary="---mime-boundary-27CFCD10.35835F91---"

-----mime-boundary-27CFCD10.35835F91---
Content-Type: application/smil; name="4620D4C5.smil"; charset=utf-8
Content-ID: <4620D4C5.smil>
Content-location: 4620D4C5.smil

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

-----mime-boundary-27CFCD10.35835F91---
Content-Type: text/plain
Content-ID: <textfile.txt>
Content-location: textfile.txt

this is a test
-----mime-boundary-27CFCD10.35835F91-----

4.) When submitting via MM7, use the <ApplicID> and <ReplyApplicID> elements defined by 3GPP TS 23.140, and/or the "Content-Type" parameters defined by JSR-205. (If NowSMS detects the Application ID parameters being set by either approach, it will automatically apply the Application ID values using both formats in the resulting MMS message.)

For example:

POST /mm7 HTTP/1.1
Host: mmsc:8002
SOAPAction: ""
Content-Length: 1973
Content-Type: multipart/related; boundary="---mime-boundary-3F95F09C.BE61A41D---";
 type="text/xml"; start="<mm7_msg>"
Connection: close

-----mime-boundary-3F95F09C.BE61A41D---
Content-Type: text/xml; charset=utf-8
Content-ID: <mm7_msg>

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header>
<TransactionID xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4" env:mustUnderstand="1">20070619140731-DD9A3699@bigkahuna</TransactionID>
</env:Header>
<env:Body>
<SubmitReq xmlns="http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4">
<MM7Version>6.7.0</MM7Version>
<SenderIdentification>
<SenderAddress><ShortCode>1234</ShortCode></SenderAddress>
</SenderIdentification>
<Recipients>
<To>
<Number>+99999999999</Number>
</To>
</Recipients>
<DeliveryReport>false</DeliveryReport>
<ReadReply>false</ReadReply>
<Priority>Normal</Priority>
<Subject>MM7 Application ID Test</Subject>
<ApplicID>destinationApp</ApplicID>
<ReplyApplicID>sourceApp</ReplyApplicID>
<Content href="cid:mms_cid" />
</SubmitReq>
</env:Body>
</env:Envelope>

-----mime-boundary-3F95F09C.BE61A41D---
Content-Type: multipart/related;
 start="<4620D4BD.smil>"; type="application/smil";
 Application-ID=destinationApp;
 Reply-To-Application-ID=sourceApp;
 boundary="---mime-boundary-B61FC9DA.135BD7DB---"
Content-ID: <mms_cid>

-----mime-boundary-B61FC9DA.135BD7DB---
Content-Type: application/smil; name="4620D4BD.smil"; charset=utf-8
Content-ID: <4620D4BD.smil>
Content-location: 4620D4BD.smil

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

-----mime-boundary-B61FC9DA.135BD7DB---
Content-Type: text/plain
Content-ID: <textfile.txt>
Content-location: textfile.txt

this is a test
-----mime-boundary-B61FC9DA.135BD7DB-----

-----mime-boundary-3F95F09C.BE61A41D-----

Note: The MMS v1.3 "Applic-ID" headers will only be delivered to an MMS v1.3 client. When deployed in an operator MMSC configuration (direct MMS delivery), NowSMS tracks the MMS version number implementation of each client account. The JSR-205 parameters will be delivered to all MMS clients.

Similarly, if posting to an operator MMSC, MMS v1.3 headers are only sent if the version number of the connection supports them. NowSMS 2007 allows an MMS version number to be associated with MM1 and MM7 connection types. (MM1 connections must be defined as "MMS Version: 1.3". MM7 connections must use the "REL-6-MM7-1-4" or later schema.) MM4 connections will receive MMS v1.3 headers if they are present, as servers supporting earlier versions should ignore these headers as extra SMTP layer headers.

If you are routing MMS messages for delivery via an operator MMSC, you will need to test to see if the operator MMSC supports the application ID headers, as some operator MMSCs might not support the JSR-205 application ID headers. In particular, there may be interoperability issues when sending MMS messages across an interoperator connection.

Note: At the time of this posting, NowSMS 2007 is not yet officially released. A pre-release version is available for download at http://www.nowsms.com/download/nowsms2007.zip.

-bn

Send an SMS to a Java app/MIDlet

It's a common task, but a confusing one. As Java becomes more widely supported on mobile phones, one of the most obvious application needs is the ability to send SMS messages to an application and have the application take some action based upon the content of the SMS message.

However, while J2ME will let an application receive messages, it will not let the MIDlet interact directly with the phone's SMS inbox. Instead, applications only receive messages that were addressed to their specific port number.

From within your MIDlet, it is relatively easy to send an SMS message to a particular port, because you just include the port number in the recipient address (sms://phonenumber:port).

However, it is not so easy (or in many cases even possible) to send an SMS message to a specific port from a conventional SMS client.

We've supported a relatively easy (if obscure) way of sending an SMS message to a specific port in NowSMS since early 2004.

With the full NowSMS 2007 release, it's going to be easier, as the "Send Text Message" web form will now include a "Destination Port" field. Alternatively, when submitting via a URL request, include "&DestPort=xxxx" or "&SourcePort=xxxx" in the URL request to specify a destination and/or source port. Or, the destination port can be specified in the recipient phone number using the format phonenumber:port. (Note: When using the phonenumber:port format, if multiple recipients are specified, the same destination port will be applied for all recipients, that being the first destination port encountered in the recipient list.)

But it is still relatively easy to send an SMS message to a specific port when using current versions of NowSMS.

From the web form, use the "Send Binary Message Other" form, specify a user data header (UDH) of: 060504xxxxyyyy Where xxxx is the destination port in hex, and yyyy is the source port in hex. (If the source port is not important, replace it with 0's.) In the "Binary Data" field, put in your text, and leave the DCS as 0. (If you want to send binary data, put the hex string for the binary data in the "Binary Data" field, and use a binary DCS value such as 4.)

If you are posting via direct URL submission, specify the user data header using the parameter "&UDH=060504xxxxxxxx", and submit the text as you normally would using the "&Text=" parameter.

For example:

http://serverip:port/?phone=phonenum&udh=06050433330000&text=this+is+a+test

The above example sends a message to port 3333 (hex value, decimal value = 13107). The source port in this example is 0.

The text of the message is "this is a test", it has just been URL escaped for encoding in a URL.

Long SMS Text Messages and the 160 Character Limit

Ok, this post may be old news to many ... but it's a question that I get asked frequently ...

SMS text messages are limited to 160 characters, but on most GSM networks it is possible to send longer text messages. These messages go out as multiple physical SMS messages that are logically reassembled into a single long text message by the recipient handset.

How does this work? What are the message size considerations? What about special characters?

In GSM environments, an SMS message can contain up to 140 bytes (standard 8-bit bytes) of message data.

To squeeze in a few extra characters, the original SMS architects defined that SMS would use a restricted 7-bit character set which contains English characters, plus a few symbols, and a few international characters for Western Europe and Greece.

To see what characters are included in the GSM 7-bit character set, see http://www.nowsms.com/discus/messages/1/1103.html. This post shows the GSM 7-bit alphabet as defined by the ETSI GSM 03.38 standard.

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)

It is worth noting that ETSI GSM 03.38 also defines a few characters that are represented by two 7-bit characters when included in a text message. A table in the post referenced above shows these characters, but since there are only a few, I will also list them here: "^", "{", "}", "\", "[", "]", "~", "" and "€".

If you want to send a message that contains characters that are not part of the GSM 7-bit character set, such as Chinese, Arabic, Thai, Cyrillic, etc., then the entire text of the SMS that actually goes out over the air needs to be encoded in the Unicode UCS-2 character set. In the UCS-2 character set, each character is encoded with 16-bits (or two 8-bit bytes). This means that an SMS message is limited to 70 16-bit Unicode characters (70 * 16 = 140 * 8).

If a message is larger than 140 8-bit bytes, then there are segmentation and reassembly standards defined, where a single logical message can be sent over the air using multiple physical SMS messages. The receiving client then has the ability to reassemble the segmented message so that it again appears as a single message on the receiving device.

When a long text message is segmented into multiple physical 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.

If you send a long text message containing only characters that are part of the GSM 03.38 character set, then each SMS segment can contain up to 153 characters. (140 bytes - 6 bytes for the concatenation header leaves 134 available bytes, or 7 * 134 = 1072 bits. The most 7-bit characters that can be packed into 1072 bits is 153.)

If you send a long text message that includes any characters that require Unicode encoding, then each SMS segment can contain up to 67 characters. (67 * 16 = 1072 bits) (Note: Some versions of NowSMS defined a 63 character limit instead of 67, so you may need an update if you are seeing a segmentation break at 63 character intervals.)

If you're submitting text via the NowSMS web interface (or direct HTTP URL submission), then NowSMS will automatically perform this segmentation to create the concatenation headers and properly encoded SMS message.

However, there are a few considerations that might be helpful to point out ...

If you are using any national language characters that don't show up correctly, then there may be a character set issue.

If the characters appear correctly when you use the built-in NowSMS web form, but they do not appear correctly when you submit via your own HTTP URL submission, then this is because NowSMS assumes that all text will be submitted using the UTF-8 character set. If you are using an alternative character set, such as the standard Western European character set (iso-8859-1) or Arabic (iso-8859-6), then you must include the character set in the URL submission using the parmater "&charset=iso-8859-1".

If there are a few incorrect characters and you are using an SMPP connection to your SMS service provider, go into the "Advanced Settings" for your SMPP connection configuration in NowSMS. Try changing the "SMSC Character Set" to the different available values to see if this makes a difference.

If the resulting SMS message is complete garbage whenever you send a long text message, and you are using an SMPP connection to your SMS service provider, go into the "Advanced Settings" for your SMPP connection configuration in NowSMS. Try changing the "Encode long text messages with 7-bit packed encoding" setting to a different value to see if this makes a difference. (The SMPP specification is vague with regard to the correct encoding to use for this type of message, and different providers have interpreted it in different ways.)

If the resulting SMS message is complete garbage whenever you send a long text message, and you are using an HTTP connection to your SMS service provider, then you may need to ask your service provider for additional guidance. It is possible to configure NowSMS to not perform any message segmentation, and to let your service provider do this by checking "Send long messages without segmentation" in the properties of an HTTP SMSC connection. NowSMS 2007 also adds an option for whether or not to "Use 7-bit binary encoding for long text messages" (NowSMS defaults to using this 7-bit binary encoding, but this confuses many HTTP SMSC implementations). Note that if you turn off "Use 7-bit binary encoding for long text messages", NowSMS will use the "URL Template Text" parameter when submitting the message to the SMSC, and you should include a @@UDH@@ replaceable parameter in that template to allow the segmentation details for the message to be included in the submission.

-bn

SMPP Error Code Handling in NowSMS

This should probably be in a FAQ somewhere, so I share it here ...


The default SMPP error code handling behaviour for NowSMS with an SMPP connection is as follows:

For most SMPP error codes, NowSMS will assume that the error is temporary, and retry message delivery with a delayed retry schedule.

The exceptions to this are detailed below: The following error conditions cause NowSMS to record a message delivery failure and NOT retry sending:

ESME_RINVDSTADDR (0x0B, invalid destination/recipient address)
ESME_RINVSRCADDR (0x0A, invalid source/sender address)
ESME_RX_R_APPN (0x66, receiver reject message)

The following error codes cause NowSMS to retry more times than the RetryMaxAttempts setting (default=20) allows:

ESME_RTHROTTLED (0x58, throttle error, slow down)
ESME_RMSGQFUL (0x14, message queue full)

For all other errors, NowSMS will retry sending the message up to RetryMaxAttempts times (default=20).

However, if you have particular error codes from your SMS provider that you need to treat as failure, you can add them to the SMPPRejectErrorCodes setting. For example, some SMPP providers have defined their own extended error codes that you need to configure NowSMS to treat as a failure without performing any retries.

For example, to treat the 0xFE error as a permanent error, you would edit SMSGW.INI, and under the [SMSGW] header, add:

SMPPRejectErrorCodes=FE

(Note that you must specify the error code value in hexadecimal.)

For error codes other than those listed above (or that are configured under the SMPPRejectErrorCodes setting in SMSGW.INI), NowSMS applies a delayed retry schedule.

The default behaviour for the delayed retry schedule works like this:

After the first error, a retry can be attempted immediately (but first NowSMS will try other pending messages in the outbound queue).

After the second error, NowSMS will wait 30 seconds before allowing the message to be retried. After the third error, NowSMS will wait 60 seconds before allowing the message to be retried. For each successive error, NowSMS waits an additional 30 seconds before allowing a retry. After 20 errors, the message will be considered as failed.

The following parameters can be applied to the [SMSGW] section of the SMSGW.INI file to provide additional control for the retry schedule:

RetryDelay=
RetryDelayMultiplier=
RetryDelayAfterAttempts=
RetryDelayMax=
RetryMaxAttempts=

The above parameters control retry behaviour for when NowSMS is submitting messages to an SMSC and an error occurs.

RetryDelay=#### specifies a number of seconds to wait to retry sending after an error condition, the default value is 30.

RetryDelayMultiplier=### specifies a multiplier to be applied for successive send failures, the default value is 1. For each failed attempt, the retry delay will be the product of RetryDelay*RetryDelayMultiplier*#FailedAttempts. To use a fixed retry delay of RetryDelay, specify RetryDelayMultiplier=0.

RetryDelayAfterAttempts=### specifies that the retry delay should only be applied after ### failed attempts, the default value is 2. NowSMS will immediately retry a failed message send until it has made RetryDelayAfterAttempts, after which it will apply a retry delay.

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

USSD and NowSMS

From time to time we get asked questions about USSD support in NowSMS.

The quick answer is that, yes, NowSMS can support USSD ... assuming that you can connect to the USSD gateway using SMPP.

SMPP extensions have been defined specifically for the support of USSD, so that you don't have to use yet another protocol.

However, before you get too excited ... let me explain how USSD works ... more from a user perspective ... not the tech nitty-gritty.

On T-Mobile in the US, you can type in #646# and press the call button ... after a short wait, a response will appear on your screen telling you how many minutes you have used that month. You can get something similar on AT&T Wireless/Cingular by typing *646# and pressing the call button. (Or on Vodafone UK, try *#100# and it will respond back with your phone number if you're having a senior moment.)

The bottom line is that there are a lot of these codes out there ... they are all operator specific ... some are available only to contract customers, some only to pay-as-you-go.

These simple request/response applications are built using USSD. From a user perspective, USSD provides something similar to a 2-way SMS, except that you generally can't save the response that you get back.

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 an 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. You need to go to the mobile operator ... and even more challenging, you need to find someone at the operator that has a clue what you are talking about.

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.

But if you are a mobile operator, USSD is convenient for some simple applications. And if your USSD gateway support SMPP, then the 2-way facility in NowSMS can be used to build a USSD request/response application.

To support USSD in SMPP, an optional parameter extension is used. This parameter must be defined by adding the following section to SMSGW.INI:

[SMPPOptions]
ussd_service_op=0501,Integer,1

When this parameter is present, if NowSMS receives a message via SMPP where this paramter is set, NowSMS will automatically append "&SMPPOption_ussd_service_op=value" to the 2-way URL. It is not necessary to add any variables to the 2-way command template, as these values will be appended automatically if present in a received message.

I'm not an expert at USSD, but people who have used NowSMS for USSD applications have told me that when sending back USSD response, it is necessary to set a ussd_service_op value when sending back the reply.

From what I have been told, usually the value that needs to be set is the same each time. 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, you can 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 that SMPP connection.

If you need to set different values for this parameter, then it is necessary to include the "&SMPPOption_ussd_service_op=x" parameter when making an HTTP request to submit a message via NowSMS. If you need to do this for a 2-way command response, see http://www.nowsms.com/support/bulletins/tb-nowsms-003.htm.

Based upon past customer discussions, sometimes it is also necessary to set the SMPP service_type value. Unlike the SMPPOptions parameter above, NowSMS supports the service_type parameter differently. To pass the service_type value to a 2-way command, the command template must include the replaceable parameter @@SERVICETYPE@@. To specify a service type when submitting a message to NowSMS via HTTP, use "&ServiceType=xxxx" in the URL request. To set a default service_type value for an SMPP connection, edit SMSGW.INI, and under the [SMPP - host:port] section, add ServiceType=xxxx.

That's my brain dump on USSD ...

There have a been a few past USSD related discussions on the NowSMS discussion board, so it may be worth searching there using a keyword of USSD ... but probably more of those discussions that I've been involved in have been over e-mail. A quick search shows the following past threads on the discussion board:

http://www.nowsms.com/discus/messages/1/20645.html
http://www.nowsms.com/discus/messages/1/16470.html
http://www.nowsms.com/discus/messages/1/11394.html

-bn

Editing Distribution Lists and Address Books in NowSMS

The NowSMS documentation doesn't provide any technical information about the format of the distribution lists and address books that are available via the web interface.

In particular, the distribution lists can be very useful. You can send a bulk SMS message to all of the phone numbers in a distribution list even if you are using direct URL submission without using the built-in NowSMS web forms.

To keep your distribution lists up-to-date, you might want to have an external application manage them, rather than making manual edits via the NowSMS web interface. This is actually quite easy to do because the distribution lists are just text files stored on the NowSMS server, and you can edit them external to NowSMS.

Alternatively, NowSMS provides an HTTP interface that can be used to create/modify/delete distribution lists, and to update the distribution list members. So you could use that interface from your application in order to keep distribution lists up-to-date.

I provided a fairly decent explanation of all this in a recent thread on our discussion board:

http://www.nowsms.com/discus/messages/485/20322.html

That thread explains the file formats for the distribution list files, and it explains the details of the HTTP interface for managing distribution lists.

The NowSMS web interface also has an address book feature. Unlike the distribution lists, the address book is only of value to users who are manually sending messages via the built-in NowSMS web interface. However, you may have a need to manage address books for your users. Similarly this can be managed either via an HTTP interface or via direct text file edits. I've provided information about this at the same link as referenced above.

-bn

Receiving MMS Messages Over a GPRS Modem - MMSINQ and MMSCDATA Directories

If you're configuring NowSMS to send and/or receive MMS messages using a GSM/GPRS (or EDGE/UMTS/WCDMA) modem, the initial setup can be a little confusing.

It's confusing because NowSMS is like a swiss-army knife of SMS and MMS messaging functionality. We've tried to make NowSMS easy-to-use for accomplishing basic messaging tasks ... but a big part of the appeal of NowSMS is its flexibility. Flexibility is great, because everyone's application needs are different.

One of the areas of confusion has to do with sending and receiving MMS messages via a modem.

When it comes to MMS capabilities in NowSMS, NowSMS can be used as either an MMSC, or it can be used as a gateway for connecting to an MMSC via a variety of different protocols (MM1, MM4, MM7, EAIF). The default configuration for NowSMS is to operate as an MMSC, but in most real-world configurations, the preference is to send/receive MMS messages via the operator MMSC, going through the modem.

There's an old link with some great information about How MMS Works which explains this in more detail. You can find this at http://www.nowsms.com/howmmsworks.htm.

And you can find information about configuring NowSMS to send and/or receive MMS messages via a GSM/GPRS (or EDGE/UMTS/WCDMA) modem at the following link: http://www.nowsms.com/documentation/ProductDocumentation/mms_notifications_and_content/Connecting_to_operator_MMSC.htm

Basically, if you're sending MMS messages via a GSM/GPRS modem, you're going to want to define an "MMSC Routing" in NowSMS with details about your modem and operator-specific MMS settings. If you're receiving MMS messages via a GSM/GPRS modem, you're going to want to configure the mobile operator settings under the "MMS Settings" button that you'll find under "Properties" for the modem in the "SMSC" list.

I also just responded to a question on our discussion board that provides some more practical detail. The poster of the original question was specifically asking about the MMSCDATA and MMSINQ directories, and my response also provides some detail about how those directories are used ... which may provide some good troubleshooting information if you are trying to configure NowSMS to send and/or receive MMS messages via a modem. The link to this discussion board posting is: http://www.nowsms.com/discus/messages/485/21262.html

-bn