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
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.
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 160×120 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 160×120 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 160×120, 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 …
User-Agent:MOT-K1/08.22.07R MIB/BER2.2 Profile/MIDP-2.0 Configuration/CLDC-1.1 EGE/1.0
User-Agent: BlackBerry8800/4.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/100
User-Agent: NokiaN95/11.0.026; Series60/3.1 Profile/MIDP-2.0 Configuration/CLDC-1.1
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:
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
(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.
For comments and further discussion, please click here to visit the NowSMS Technical Forums (Discussion Board)...