Receiving MMS fails if MMS contains only image (no text)

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): (but with jolla-messages and jolla-messages-settings downgraded to versions from 4.2 to fix the current bug that makes it impossible to send MMS at all)
HARDWARE (XA2, X10, X10 II, …): XA2 Ultra
REGRESSION: (compared to previous public release: Yes, No, ?): No idea.

MMS reception fails if MMS contains only image (or audio) without title text.


After having fixed the problem with not being able to save pictures received by MMS (as reported here), and then the bug making it impossible to send MMS (as reported here) by downgrading jolla-messages and jolla-messages-settings to version from 4.2.x.x OS release), sending MMS started working, but MMS reception still kept failing in some cases.

It turned out that if the MMS message (sent from iPhone 6s) contains text (title) in addition to the image then it is received correctly, but if the MMS contains only image, without any text, then message receiption ALWAYS fails. MMS logger reports: [mms-task-decode] ERROR: Failed to decode MMS PDU.

It is 100% reproducible.



  1. Have someone send to you MMS with just the image, no title
  2. MMS receiption fails. MMS logger reports “error decoding MMS PDU”
  3. Have someone send to you MMS with both image and some text in the title
  4. MMS received correctly, no errors.


MMS received.


MMS receiption failed.



Reproducible in

Sorry but I can’t reproduce.
Xperia 10ii, 4.3.15, o2 germany, mms sent from iphone, tmobile germany.

@Inte iPhone has two text fields in MMS: the body text (below the image) and Subject / Title (above the image). I can receive an MMS without any body text, but not without Subject. An image sent without any text fails on SFOS, whereas if I add any subject text (even just one character) to the same image then it is received correctly.

1 Like

this is an MMS I received only recently - w/o any subject or text…

@Inte Lucky you. I can’t even get my operator’s MMS messages (when someone leaves a message in my voicemail my operator sends it to me as an audio file via MMS). Those messages don’t have any subject text (only some message body text + audio file attached) and their reception always fails, just like it is with images.

@slava 's MMS logger always shows in such case:

[mms-task-decode] ERROR: Failed to decode MMS PDU.

Well, considering that also @michan reproduced this bug, it looks like yet another operator-dependent issue, just like the ofono problem with rejecting calls (i.e. it manifests itself on specific network configurations, or maybe MMS versions used by the operator, or MMSC configuration or whatever else). And just like with ofono, also in this case I’ve never experienced such an issue on any other phone model, so it’s still somehow SFOS-specific.

MMS PDU decoding error is an interesting and very unusual case. Would you mind sending a tarball saved by MMS logger (containing the problematic PDU) to

@slava Sure! I think that I already deleted those old logs but I’ll record new ones tomorrow and I’ll submit them.

Hi @slava, I’ve just sent MMS Logger logs to as requested.
I hope you won’t mind that I removed some personal information from it (phone numbers, imsi, etc.)
If I can be of any further help, please let me know.

P.S. The failed MMS message that the logs I sent you refer to was sent from BlackBerry Z10 with a T-Mobile Poland (260 02) SIM card. Right after its reception failed on my SFOS 4.3 XA2 Ultra, I resent the very same message from the BB Z10 to my wife’s iPhone where it arrived without any problems. From her iPhone, my wife tried to then forward it to my SFOS XA2, where it failed again, but then she successfully sent it to the Z10. So the problem only appears on SFOS.

Can’t reproduce on XA2 plus,
Iphone has a subject field if you’ve configured message app to do so, which is not the default.

Received, thanks. The PDU is there, fails to get decoded, as described. I’ll fix that.


Yeah, but failure to receive on SFOS apparently doesn’t depend on whether this field is enabled on the iPhone or not, but whether the actual subject text is present or not. And that probably in combination with some specific mobile network config, considering that only some people can reproduce it. Well, at least that is what my tests suggest, given that as soon as I add any subject, even just one letter, the same message that previously failed without it, gets received correctly. BlackBerry BB10 (Z10, Passport) do not have such a subject field at all, so there’s no way to enter any subject, and thus all messages sent from the Z10 or Passport fail on my XA2…

Fantastic! Thank you very much Slava!

It appears that your M-Retrieve.conf PDU is lacking the Date header which is marked as Mandatory for this kind of PDU by the MMS specs. Strictly speaking, this PDU is invalid. Then is shouldn’t be recognized by Android too:


I can’t speak about such technical details that I am not familiar with. All I can say is that those MMS messages that fail are absolutely normal, standard MMS messages sent from either iPhone 6s or BlackBerry Passport / Z10. There are no problems whatsoever with receiving them on any other phone / OS, whereas they fail on SFOS. Same message sent to my XA2/SFOS fails whereas sent to the iPhone or Blackberry is received correctly.

Moreover, as I already wrote, I discovered (and confirmed by multiple tests) that MMS messages sent from the iPhone 6s fail as long as there is nothing in the “Subject” field. If I send a plain image without subject, its reception fails on SFOS (and PDU decode error is in logs). If I add to it even just one letter in the “Subject” field, it is received correctly, without any PDU decode errors.

So it makes me think that it isn’t the absence of Date header that causes this PDU decode error (and reception failure) if its occurence is clearly tightly connected with the Subject text being present or not. Also, I can’t believe that iPhone 6s sends invalid MMS messages, because those same messages are correctly received on virtually any other phone/OS and only fail on SFOS.

I can record a video showing you how this PDU error (and receiption failure) directly results from the “Subject” text being entered or not.

I’ve had MMS messages that failed to load with a forever spinning circle as well. Just dismissed those as another WIP Jolla thing.

@slava OK, so here’s the video (blurred to mask all those personal details):

What you can see on this video:

  1. I am sending a plain image (no text, no subject, just picture) from the iPhone 6s to XA2 with SFOS - message reception FAILS (PDU decode error appears in MMS Logger)
  2. I am once again selecting the same image, the same recipient
  3. I am adding some random 2 characters in the “Subject” field and resending
  4. This time the MMS is received successfully.

Well, that’s it.

Could you send me MMS log of a successful reception?

@wetab73, by reading this thread, I realise that you have only supplied @slava with a log of a failing MMS generated by one of your two Blackberry OS 10 devices (Passport and Z10).

I.e., AFAIU you have not supplied @slava with a log of a failing MMS generated by your wife’s iPhone 6s, yet. Just to check, if this is exactly the same error case.
Plus the same MMS with a single word as title / subject, to cover the non-failing case, in order to make the difference between these two iPhone MMSes obvious. This will implicitly cover Slava’s last request, too.

@olf In all three cases (iPhone 6s, Passport, Z10) there was the same PDU decode error in MMS Logger output, and everything else in the log also looked the same. Indeed, the log I sent to @slava was from the Z10 and I didn’t include the iPhone log, but that’s simply because the error in case of the iPhone was exactly the same. I didn’t see the point in sending both also because removing private information (sender and recipient phone numbers, imsi, imei, etc., that I am not overly enthusiastic to share) from multiple tarballs would take a lot of time.

The test procedure looked as follows:

  1. I sent plain picture from the Z10 to my SFOS XA2, where it failed. Checked the MMS Logger output, there was PDU decode error there.
  2. I sent that very same message (without any modifications, using an option to forward the same message to another recipient) from the Z10 to the iPhone 6s, where it was received successfully
  3. From the iPhone, I sent that same image to the SFOS XA2, where it failed again, and once again there was the same PDU decode error in the log
  4. I typed some random word in the Subject field and resent the message from the iPhone to the SFOS XA2, and this time it was successfully received, without any errors in the log.

Well, that’s it…

I get that same PDU decode error also in case of MMS messages that my operator sends to me whenever there is a new message in my voicemail. Such MMS contains an audio file and some text (but not subject). I’ve been receiving those messages for years without any problems on all other phones but not a single time on SFOS where they always fail, with that PDU decode error in the log.

@slava, I will have access to both those phones during the weekend, so I will send the log to you within two days at the latest.

Actually, I was wrong about the Date. It’s there, but the header parser stops at the Subject field, which is broken, this time according to WSP spec. The subject value is 2 bytes:
0x7f 0x00. That’s Quote and End-of-string characters according to WSP spec:

Quote = <Octet 127>
End-of-string = <Octet 0>

However the same section of WSP spec says this:

Text-string = [Quote] *TEXT End-of-string
; If the first character in the TEXT is in the range of 128-255, a Quote character must precede it.
; Otherwise the Quote character must be omitted. The Quote is not part of the contents.

Since the subject is empty, the first character in the TEXT is not in the range of 128-255 (there’s no first character), therefore the Quote character must be omitted. But it’s there. The subject value is encoded incorrectly.

So the subject is indeed involved. If I change WSP parser to interpret 0x7f 0x00 as an empty string, the PDU gets parsed successfully.