04 March, 2016
Nokia 220 MMS Size Limit
We have a Nokia 220 around that is the subject of a long term use review. As we used that mobile, we noticed that the multimedia messaging (MMS) system was a little flaky—some MMS were received without difficulty other MMS messages were never downloaded, producing the "Can't download message" error. In rudimentary investigation of the critical factor, we noticed that it seemed to be the larger MMS messages that were failing. The MMS size limit on the AT&T network is one megabyte (1 MB), pending device support. Since it appeared that the Nokia 220 did not support MMS messages of this size, we set out to measure the exact MMS size limit for reception on the Nokia 220.
Methods
The first challenge we faced was working out a method by which we could deliver an MMS message with defined payload sizes. The AT&T MMS appliance is strict about what it will deliver as an MMS message, and it will happily (re)compress your media (*.mp3 audio files or *.jpg image files) in order to limit network traffic. The MMS appliance will also prevent the delivery of MMS messages to various mobiles based on a set of rules about what file types are "suitable" for your mobile. For the Nokia 220, which doesn't appear anywhere in the AT&T device database, the AT&T MMS appliance will happily deliver arbitrary file types. This allows us then to skip trying to generate image files which differ by one byte (a decidedly losing battle) or inserting extra data payloads into known file types to generate the necessary granularity. We can then simply write a program to generate files of any size to use as our testing set.
With this first hurdle cleared, we wrote the following program (bytes) to generate binary data of arbitrary size.
$ cat bytes
#!/usr/bin/perl

$data = pack("B8", "01111000");

open(my $file, '>:raw', $ARGV[0] . ".byt");

for ( my $i = 0; $i < $ARGV[0]; $i++ ){
  print $file $data;
}

close($file);
$
The bytes program generates an 8 bit binary number (01111000 binary or 78 decimal or the character "x" in the ASCII character table) and writes it to a file as many times as requested by the first command line argument (that argument is also used as the file name in order to help keep track of all the files differing by a single byte). The bytes program is invokes as follows,
$ bytes 300000
and generates an output that looks like this.
$ ls -al 300000.byt
-rw-r--r-- 1 pmob users 300000 2016-02-29 13:57 300000.byt
$ vi -b 300000.byt
 offset    0  1  2  3   4  5  6  7   8  9  a  b   c  d  e  f  0123456789abcdef
------------------------------------------------------------------------------
00000000 <78>78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000010  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000020  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000030  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000040  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000050  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000060  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000070  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000080  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000090  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000000a0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000000b0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000000c0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000000d0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000000e0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000000f0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx

 offset    0  1  2  3   4  5  6  7   8  9  a  b   c  d  e  f  0123456789abcdef
------------------------------------------------------------------------------
00000100  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000110  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000120  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000130  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000140  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000150  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000160  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000170  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000180  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
00000190  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000001a0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000001b0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000001c0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000001d0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000001e0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx
000001f0  78 78 78 78  78 78 78 78  78 78 78 78  78 78 78 78  xxxxxxxxxxxxxxxx

Read 300000.byt, 0 lines, 300000 chars                           1,63 Command
This will allow us to generate files of any size to feed into the MMS pipe to see if the Nokia 220 will successfully receive them.
Since we were already at a console, the easiest was to initiate the multimedia message was through the AT&T email to MMS gateway. That gateway is accessed by sending an email message, with the media payload as an attachment, to ten-digit-number@mms.att.net.
That's about it for the methods, other than having the Nokia 220 on to receive the messages and media (success) or not (failure).
Results
To start, we knew that the Nokia 220 had no trouble sending any picture its camera captured as an MMS message. The 2 MP camera in the Nokia 220 captures images in jpeg format that always come in under 300 KB. That gives us a good starting place on file size as the camera output is certainly tuned to the size which could be shared via MMS messaging. Here is the full list of files we generated in our testing. You can judge our testing sequence by timestamps (clearly not the most direct route to finding the answer, but we'll report all our data so it appears that we worked hard, if not necessarily efficiently).
$ ls -alh *.byt
-rw-r--r-- 1 pmob users 293K 2016-02-29 13:57 300000.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 12:54 306500.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 12:56 306750.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 12:59 306850.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:04 306888.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:11 306895.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:32 306896.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:28 306897.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:22 306899.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:13 306900.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:35 306901.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:36 306902.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:37 306903.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:08 306905.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 13:02 306925.byt
-rw-r--r-- 1 pmob users 300K 2016-03-01 12:51 307000.byt
-rw-r--r-- 1 pmob users 301K 2016-03-01 12:21 308000.byt
-rw-r--r-- 1 pmob users 312K 2016-03-01 12:20 318546.byt
$ ls -al *.byt
-rw-r--r-- 1 pmob users 300000 2016-02-29 13:57 300000.byt
-rw-r--r-- 1 pmob users 306500 2016-03-01 12:54 306500.byt
-rw-r--r-- 1 pmob users 306750 2016-03-01 12:56 306750.byt
-rw-r--r-- 1 pmob users 306850 2016-03-01 12:59 306850.byt
-rw-r--r-- 1 pmob users 306888 2016-03-01 13:04 306888.byt
-rw-r--r-- 1 pmob users 306895 2016-03-01 13:11 306895.byt
-rw-r--r-- 1 pmob users 306896 2016-03-01 13:32 306896.byt
-rw-r--r-- 1 pmob users 306897 2016-03-01 13:28 306897.byt
-rw-r--r-- 1 pmob users 306899 2016-03-01 13:22 306899.byt
-rw-r--r-- 1 pmob users 306900 2016-03-01 13:13 306900.byt
-rw-r--r-- 1 pmob users 306901 2016-03-01 13:35 306901.byt
-rw-r--r-- 1 pmob users 306902 2016-03-01 13:36 306902.byt
-rw-r--r-- 1 pmob users 306903 2016-03-01 13:37 306903.byt
-rw-r--r-- 1 pmob users 306905 2016-03-01 13:08 306905.byt
-rw-r--r-- 1 pmob users 306925 2016-03-01 13:02 306925.byt
-rw-r--r-- 1 pmob users 307000 2016-03-01 12:51 307000.byt
-rw-r--r-- 1 pmob users 308000 2016-03-01 12:21 308000.byt
-rw-r--r-- 1 pmob users 318546 2016-03-01 12:20 318546.byt
$ ls -alrt *.byt
-rw-r--r-- 1 pmob users 300000 2016-02-29 13:57 300000.byt
-rw-r--r-- 1 pmob users 318546 2016-03-01 12:20 318546.byt
-rw-r--r-- 1 pmob users 308000 2016-03-01 12:21 308000.byt
-rw-r--r-- 1 pmob users 307000 2016-03-01 12:51 307000.byt
-rw-r--r-- 1 pmob users 306500 2016-03-01 12:54 306500.byt
-rw-r--r-- 1 pmob users 306750 2016-03-01 12:56 306750.byt
-rw-r--r-- 1 pmob users 306850 2016-03-01 12:59 306850.byt
-rw-r--r-- 1 pmob users 306925 2016-03-01 13:02 306925.byt
-rw-r--r-- 1 pmob users 306888 2016-03-01 13:04 306888.byt
-rw-r--r-- 1 pmob users 306905 2016-03-01 13:08 306905.byt
-rw-r--r-- 1 pmob users 306895 2016-03-01 13:11 306895.byt
-rw-r--r-- 1 pmob users 306900 2016-03-01 13:13 306900.byt
-rw-r--r-- 1 pmob users 306899 2016-03-01 13:22 306899.byt
-rw-r--r-- 1 pmob users 306897 2016-03-01 13:28 306897.byt
-rw-r--r-- 1 pmob users 306896 2016-03-01 13:32 306896.byt
-rw-r--r-- 1 pmob users 306901 2016-03-01 13:35 306901.byt
-rw-r--r-- 1 pmob users 306902 2016-03-01 13:36 306902.byt
-rw-r--r-- 1 pmob users 306903 2016-03-01 13:37 306903.byt
$
So, which messages made it through and which didn't? The easiest way to illustrate that is in the table below.
Size (bytes)
Delivery
300000
Success
306500
Success
306750
Success
306850
Success
306888
Success
306895
Success
306896
Success
306897
Success
306899
Success
306900
Success
306901
Success
306902
Success
306903
Failure
306905
Failure
306925
Failure
307000
Failure
308000
Failure
318546
Failure
Conclusions
There it is. The largest MMS message which was successfully retrieved by the Nokia 220 was 306902 bytes on the AT&T network.
Now, to illustrate exactly what that number of bytes means, we've left all our test files in the output of ls above. You'll quickly notice that we weren't as efficient as we could have been in moving directly to the maximum MMS size. That inefficiency was for two reasons. The first is that we didn't fall into the pattern of splitting the range evenly (the basic bisection algorithm) because we were hoping the maximum closer to the high end based on our experience with the Nokia 220 camera app—not so. And shame on us for holding onto a faulty assumption for so long.
The second reason, however, is much more important. In order to make our job a little easier, we were including a bit of text in the message along with the MMS data. Just to be sure we had it right, we sent an MMS message with a slightly larger payload and no text—which arrived at the Nokia 220 just fine. That sent us back to narrowing the size range again. A few more files, a few more MMS messages and then the answer. The conclusions we can draw from that anecdote is that the total size of the message, text and MMS payload is limited on the Nokia 220. While the number we've measured above is 306902 bytes, there will always be a little bit of data required for the message itself—whatever the sender includes as text as well as the data defining a message on the network. The 306902 bytes reported above is the practical size limit on the AT&T network.
Home | Privacy Policy |  Page generated in 0.00697 seconds.