Mobile Number Portability (MNP) and the NowSMS MMSC

The NowSMS MMSC implements a dynamic MMS routing callback facility for environments where more advanced MMS routing capabilities are required.

The standard NowSMS MMSC configuration allows for MMS routing based upon phone number prefixes. However, in MNP environments, it may be necessary to query a database to determine how to properly route an MMS message.

Dynamic MMS routing callbacks also allow for MMS routing control based upon who submitted the MMS message. For example, it may be desirable to block MMS sending to international destinations for some or all MMS VASP accounts.

Here's the text that I usually cut and paste when people ask how to implement the dynamic MMS routing callback:

When the MMS Routing callback is enabled in NowSMS, each time the MMSC receives a message, it will connect to a configurable customer-provided routing callback URL, passing the message recipient to the URL. The customer provided URL can return a response to indicate that the message should be routed via a specific route defined in the "MMSC Routing" page of the NowSMS configuration dialog, or the response can indicate that the message should be rejected.

The MMS routing callback URL is defined in the MMSC.INI file, under the [MMSC] section header:

MMSRoutingURL=http://server.name/path

The variables listed below will be added to the MMSRoutingURL when the URL is executed by the gateway as HTTP GET (CGI-style) parameters.

Type=MMSRouteCheck (Note: Future "Type" values may be added in the future.)

From=SenderPhoneNumber or e-mail addressVASPIN=VASPname (present if the message was received via a specific account defined in the "MMSC VASP" list)

To=RecipientPhoneNumber

Example:

http://server.name/path?Type=MMSRouteCheck&From=%2B1234567&VASPIN=test&To=%2B9999999999

(Note: The "%2B" in the above examples is standard URL escaping for the "+" character.)

To specify which of the routes defined in the "MMSC Routing" list should be used to route this message, the URL must return a standard HTTP 200 OK response, and include the following text somewhere in the response:

Route=xxxxxxx

"xxxxxxx" should match an "Account Name" defined in the "MMSC Routing" list, or it can use the predefined values of "Direct" (signifying MMSC Direct Delivery), "WAPPush" (signifying "Convert to Multimedia WAP Push"), or "Deny" (signifying the MMSC should reject the message).

If it is possible to route the message via one of several defined routes, multiple routes can be returned in the response, separated by ":". For example:

Route=xxxxxxx:yyyyyy:zzzzzz

In the above case, the message could be routed through any of the listed routes.


Although that explanation is fairly complete, we're frequently asked for an example.

Examples can be helpful. But we've always been hesitant to provide an example because this routing callback script runs on a separate external web server. That means that the script can be written in whatever web development environment the customer is most familiar with. For example, it could be PHP, ASP, Perl, Ruby on Rails, or numerous other environments.

We decided to provide a PHP example.

Blogger is not good for posting code examples, so you can download the PHP example at the following link: http://www.nowsms.com/download/mmsroute.php.txt.

More Thoughts on the NowSMS Security Issue

An additional thought ... if you are concerned about the potential security issues described in the previous blog entry, but you are also concerned that you do not want to hastily update to NowSMS 2008 without additional testing for your specific application(s), then you may want to enable Data Execution Prevention within Windows on the PC or server that is running NowSMS.

As a practice, we enable this setting on all of our servers, as well as our development and testing machines. This Windows configuration setting enables extra protection in the processor and within Windows to prevent this type of stack buffer overflow from allowing any malicious code to be executed.

The downside is that some software may experience difficulty with this setting being enabled, but if necessary, it is possible to disable the setting for specific applications or services that encounter problems.

If NowSMS is running as a dedicated server, I think it is a no-brainer to enable this setting. And in my opinion, it is a good idea to enable this setting on most servers.

The Data Execution Prevention setting exists in Windows XP Service Pack 1 and higher, Windows 2003 Server, Windows Vista and Windows 2008 Server. In most of the server editions of Windows, the setting is enabled by default.

To configure this setting, use the "System" option in the Windows Control Panel. Select "Advanced" / "Performance" / "Settings" / "Data Execution Prevention". The options are to enable this setting for "essential Windows programs and services only", or for "all programs and services except those I select". Selecting "all programs and services except those I select" enables protection against malicious code attacks that target stack buffer overflows.

-bn

NowSMS 2008 and Important Security Issues

The 2008 edition of the Now SMS/MMS Gateway is now available for download at http://www.nowsms.com/downloads/.

While the primary new feature of this version is improved performance and scalability for configurations that require throughput of 200 messages per second and higher, we want to draw the attention of all customers to this release, as it addresses a security issue that was recently posted on the internet at http://secunia.com/advisories/29003/.

At this time, we are not aware of any software that exploits these buffer overflow vulnerabilities for malicious purposes, nor do we know for certain that it is possible to exploit these vulnerabilities for such purposes, but we do believe that it is in the best interest of customers to update to NowSMS 2008, which addresses these vulnerabilities.

The proof of concept exploit code that has been published on the internet to highlight these vulnerabilities can trigger an internal restart of the NowSMS service, and could be used for a denial of service attack. It may be possible that variations of this attack could be used for other purposes, including remote system access (the full extent of potential vulnerability is not known).

This proof of concept code works by sending certain invalid requests to either the NowSMS HTTP/web interface port (the HTTP interface of the "SMS Gateway" component, not the HTTP port of MMSC), or the SMPP server, if enabled. The HTTP exploit can be blocked by using the "IP Address Restrictions" setting on the "Web" page of the NowSMS configuration dialog, and explicitly defining all IP addresses that are allowed to access the NowSMS web interface. The SMPP exploit can only be blocked not enabling the SMPP server (it is not enabled by default), or blocking access to the SMPP server port via a firewall that is external to NowSMS.

To address these vulnerabilities, all NowSMS customers are advised to either limit access to these affected server ports, and/or update to NowSMS 2008. The NowSMS 2008.02.22 update is being made available free of charge to all licensed customers of NowSMS 2006 and 2007, even if they do not have an up-to-date maintenance and enhancements agreement. (Access to future NowSMS 2008 updates will require an up-to-date maintenance and enhancements agreement.)

More information about the NowSMS 2008 release:

NowSMS 2008 offers dramatically improved speed and performance for configurations that require messaging throughput of 200 messages per second and higher. In particular, the performance of delivery receipt message id tracking in SMPP environments has improved substantially so that message sending rates in excess of 200 messages per second are easily sustainable for extended periods of time, even as delivery receipts are received at a similar rate. Message id assignments for multipart messages have also been modified to provide for uniqueness.

An improved queuing mechanism offers improved performance for processing bulk messaging queues, and the async mode SMPP implementation has been optimised to provide for maximum throughput.

An XML-based query interface has been added to allow for external reporting of operational and performance statistics including SMSC connection status and messaging throughput.
MM7 support has been enhanced to allow more flexibility in modifying the XML output to allow for quirks in early versions of the MM7 specification, and questionable MM7 implementations by some MM7 service providers. Digest Authentication support has also been added for external MM7 connections.

Support has been added for additional Open Mobile Alliance standards, including DRM 2.1 ROAP Triggers, which are now supported via the PAP (Push Access Protocol) and XML Settings interfaces.

Additional release notes regarding the NowSMS 2008 Edition can be found in the following post: http://www.nowsms.com/discus/messages/53/23641.html

Sending MMS from the Command Line

Last time, I posted a Windows JScript file that could be used to enable the sending of OMA Client Provisioning (XML Settings) documents from a command line interface.

Pretty cool?

Well, I thought so. But it is of somewhat limited usage to the average NowSMS customer, as the volume of OMA Client Provisioning messages being sent out via NowSMS is far less than messages of other types.

What would be really useful would be to expand upon the SMS Command Line interface example to allow the sending of MMS messages from a command line interface.

So I thought the ability to post an OMA Client Provisioning document via a command line interface was a good start toward the ultimate goal of a script that could post MMS message content from a command line interface.

But I was wrong. The issue was that an OMA Client Provisioning document is a text XML document. Windows JScript has great capabilities for processing text files, but binary files are another story, so it is more challenging to post an image (GIF/JPEG) to a server via JScript.

After quite a few frustrating attempts, I realised that while it might not be possible using JScript, it could be possible using VBScript instead.

Of course, I have zero VB or VBScript experience.

But I can surf the net to find examples that I can hack like the best of them.

To submit an MMS message to NowSMS, there are several different protocols that could be used: MM7 (XML HTTP POST), MM4 (SMTP based), MM1 (HTTP based), EAIF (MM1 with additional headers), or a proprietary URL submission technique. These options are described in greater detail at http://www.nowsms.com/documentation/ProductDocumentation/mms_notifications_and_content/Submitting_MMS_Messages.htm.

I wanted to use the proprietary URL submission technique, because the encoding is a bit simpler. This is the interface that is used when you use the "Send MMS Message" web form in the NowSMS web interface. It uses "HTTP File Upload" or an HTTP POST of the "multipart/form-data" MIME type.

I found some great examples of how to perform "HTTP File Upload" submissions at http://www.motobit.com/tips/detpg_uploadvbsie/ ... and I went about to learn enough VBScript to complete this script.

The resulting code is not pretty. (Is VBScript ever?) But, it is functional.

The result is sendmms.vbs. You can right-click on the file name to download and save this file.

Assuming that the script file is saved as a file named smsmms.vbs, you would issue the following command to send an MMS message:

cscript sendmms.vbs recipient[,recipient2,recipient3...] filename [filename2] [filename3...] [variable=setting]

recipient can contain either one recipient phone number, or a comma delimited list of recipients, e.g., +44777777777,+44777777778 (important - do not include spaces)

filename is the name of a local file to be included in the MMS message. Similar to when submitting an MMS message via the "Send MMS Message" web form, you may specify multiple files that NowSMS will package up as an MMS message. (Note: NowSMS identifies content types based on the file extension of the submitted file, see the MMSCTYPE.INI file for the default list of file extension to MIME type mappings.)

variable=setting can specify additional URL parameters supported by NowSMS, such as:

• MMSSubject=SubjectLine
• MMSFrom=SenderAddress
• MMSDeliveryReport=Yes
• MMSReadReport=Yes
• MMSPriority=High Normal Low
• MMSMessageClass=Personal Informational Advertisement
• MMSForwardLock=Yes
• DRMRestrict=Yes
• DRMRestrictTextXML=Yes
• DRMPermissionPlay=Yes
• DRMPermissionDisplay=Yes
• DRMPermissionExecute=Yes
• DRMPermissionPrint=Yes
• DRMConstraintCount=##
• DRMConstraintStart=yyyy-mm-dd
• DRMConstraintEnd=yyyy-mm-dd
• DRMConstraintInterval=##

Note: If the Subject line contains a space character, put quotes around the setting, e.g., "MMSSubject=This is a test message"

Examples:

cscript sendmms.vbs +4477777777 image.gif filename.txt "MMSSubject=This is a test message"

cscript sendmms.vbs +4477777777,+4477777778 image.gif "MMSText=This is some message text" MMSFrom=+44777777779 MMSSubject=Test

cscript sendmms.vbs +4477777777 image.gif "MMSText=The content of this message has been forward locked" "MMSSubject=Forward Lock Test" MMSForwardLock=Yes


-bn


P.S. - If you want to send an Multimedia WAP Push instead of an MMS message, include a "variable=setting" parameter of MMSWAPPush=Yes ...

Send OMA Client Provisioning (OTA XML Settings) from the Command Line

Three years ago on our discussion board we posted a simple Windows JScript that could be used to send an SMS message via NowSMS using a command-line interface. If you're not famliar with the script, then you can find more details at http://www.nowsms.com/support/bulletins/tb-nowsms-008.htm.

In the three years that have passed, I've referenced that script many times. After all, while the HTTP interface into NowSMS offers a great deal of flexibility, it is not always easy to add an HTTP interface on to an existing application. Sometimes a simple command line interface is easier to get started with ... it's easier to understand, and provides immediate feedback.

In a recent posting on the NowSMS discussion board, I was asked if there was a similar command line interface that could be used to send an OMA Client Provisioning (XML Settings) document.

I thought about all of the times that people had asked me for different variations of that script for sending different types of messages beyond the simple SMS text message ... and I thought about the wasted hours that I had spent trying to write different scripts ... frustrated by the fact that I simply was not very well versed in JScript.

Still, it sounded like a challenge worth revisiting ... and modifying the script for this purpose was actually easier than I thought it would be.

The result is sendota.js. You can right-click on the file name to download and save this file.

Assuming that the script file is saved as a file named smsota.js, you would issue the following command:

cscript sms.js PhoneNumber1[,PhoneNumber2,...] OTAFilename.xml [PINValue] [USERPIN NETWPIN]

(cscript.exe is the Windows Script Host, which is a component of Windows which should be located in the \Windows\System32 directory.)

Examples:

cscript sms.js +44777777777 settings.xml
cscript sms.js +44777777777,+44777777778 settings.xml
cscript sms.js +44777777777 settings.xml 1234
cscript sms.js +44777777777 settings.xml 1234 USERPIN

This script can be used to send XML Settings documents for any of the document types currently supported by NowSMS, including:

1.) OMA (Open Mobile Alliance) Provisioning Content (root XML element )

2.) OMA (Open Mobile Alliance) DRM Rights Objects (root XML element )

3.) WAP Push Service Indication, Service Load and Cache Operation (root XML element , or )

4.) OMA (Open Mobile Alliance) E-Mail Notification (EMN) (root XML element )

5.) Nokia/Ericsson Over The Air Settings (OTA) Specification (root XML element )

6.) Nokia/Ericssson SyncML OTA or Wireless Village Settings (root XML element or )

A "PINValue" can be associated with many of the XML settings types to provide a layer of authentication to the message. Many devices will allow you to send XML settings without a PIN, but some will require a PIN to be present before the settings will be accepted.

There are three different types of PINs, depending on the "PINType" setting.

The simplest "OTA PIN Type" is "USERPIN" (User PIN). This setting indicates that a short PIN code (often 4 digits) is supplied as the "OTA PIN". When the user receives the OTA settings message, they will need to supply this PIN code in order to be able to open the message and apply the settings. If a "PINValue" is specified, but a "PINType" is not, then USERPIN will be assumed.

"NETWPIN" (Network PIN) indicates the PIN is a network PIN code. In the GSM environment, this is the IMSI number associated with the SIM card in the device. (Hint, if you want to experiment with determining the PIN card associated with a SIM, you can put the SIM into a GSM modem and the AT+CIMI command to return the IMSI. However, not all GSM modems support the AT+CIMI command.) When the device receives the settings, if the NETWPIN does not match the IMSI, the settings will be discarded.

An additional type of PIN, known as "USERNETWPIN" also exists, which indicates a combination of the USERPIN and NETWPIN types. To use this OTA PIN type, specify the OTA PIN as the IMSI number associated with the SIM card in the device, followed by a ":" character, followed by a USERPIN (e.g., 1234567889012345:1234). When the device receives the settings, the user will be prompted for a PIN. This user supplied PIN, and the SIM card IMSI, must match in order for the settings to be accepted.

-bn

P.S. - Now the real challenge ... can I hack this script further to create a script that can easily send MMS messages from the command line, uploading local content objects from the script? Stay tuned ....

Multiple Modems for Sending Outbound MMS

File this as a "not so obvious" configuration feature of NowSMS....

When you are sending MMS messages via an operator MMSC using a GRPS(/EDGE/UMTS/WCDMA) modem, NowSMS only allows you to designate one of the modems as the "Default Route" for outbound MMS message routing.

So, if you have multiple modems installed, all messages are sent via only one of the modems, unless you define prefix mappings to route different phone number prefixes to different modems.

A frequently asked question is, how do you configure multiple default routes so that messages can be simultaneously routed via multiple modems?

The answer is to edit the individual routing definitions for each modem, and put "*" in the "Route messages to this account for recipient phone number(s)" field. This setting works the same as designating a route as the "Default Route" (and takes precedence over the actual "Default Route" setting).

Note that some versions of NowSMS may display a warning message: "To specify this route as the default outbound route for MMS message delivery, please select this route as the 'Default Route' on the next dialog." However, you can ignore this warning. (The reason for this warning is that very old versions of NowSMS did not have the "Default Route" option, the only way to set a default route was to put a "*" in the "Route messages..." field. The "Default Route" setting was easier for people to understand, but we kept the routing logic in place to support the "*" setting as well.)

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