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

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:

https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/telephony/common/com/google/android/mms/pdu/PduParser.java#1922

@slava

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 4.3.0.15 - 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.

2 Likes

@slava Thank you so much for having a further look into this! And I’m glad that I was right that subject is involved. But it’s strange, anyway, as it would mean that multiple sources (BlackBerry BB10 phones, the iPhone, and also my operator’s voice mail MMS service) produce MMS messages with such broken headers. Or maybe the phones generate correct header but it is the operator’s MMSC (or whatever else is involved on the way between the sender and me) that currupts the header somehow?

Anyway, other phones / OS seem to be somehow immune to this issue if the same MMS that fails on SFOS, sent from the Z10 to the iPhone (and vice versa) is received correctly. So maybe if the SFOS parser encounters this error, it should ignore it, or interpret it as an empty string like you changed it? Maybe that’s how other systems handle it and that’s why they correctly receive such messages?

P.S. I didn’t have the opportunity to get those logs for you yet. I should be able to do it on Sunday. Do you still need them?

Android isn’t so strict, and I’m leaning towards relaxing the parsing rules too.

Yes, please. I’m curious how Subject is encoded there.

2 Likes

@slava, I’ve just sent the logs to your email. I included two MMS Logger tarballs: one for successful MMS delivery (with some text in the Subject field) and the other one for failure / PDU decode error (same image but without subject). Both messages were sent from the iPhone 6s with Polish T-Mobile SIM card to XA2 Ultra / SFOS 4.3.0.15.

1 Like

Apparently the bug I encounter might be another one, because some MMSes should contain text according to the senders. I have been receiving fail-free MMSes earlier. I think last time was in October. First faulty MMS was received in December. So at first I thought it might be the same bug.

When I tap to download the MMS it’s just chewing and nothing else happens. There is nothing new in the MMS logger after I tap to download.

Presence or absence of message body text is irrelevant. It is lack of subject text what’s causing this problem.

2 Likes

Hi @slava, I just wonder, did you get the logs I sent you a week ago, and did they confirm your findings? Are there going to be some changes addressing this issue, e.g. by relaxing the parser’s rules? Thank you.

@slava Can you please advise if it was ever fixed and made it to any of the recent OS updates? As of 4.4.0.64 I still cannot receive MMS from my wife’s iPhone if she forgets to type that freaking “Subject” text.

What’s worse, since 4.4.0.58 I cannot send MMS to anyone if I first manually don’t resize the image to <1 MB, i.e. below the attachment size limit. Before 4.4.0.58 I could send any image (e.g. a multi-megapixel photo taken directly by the camera without any manual processing) as it (apparently) used to be automatically resized. Not anymore.

Well, as there has been no response from @slava since February, I would like to just say that the problem is still unresolved.

I see that @slava responds in other threads while here he (she?) stopped responding in mid February, so I guess it is unlikely to see any progress with this issue. Which is sad, because I did my best to help fixing it - collected and sent multiple logs, etc.

Anyway, MMS support is one huge mess, including:

  • failure to receive MMS if it doesn’t contain subject text. I can’t even receive my operator’s voicemail messages (every new message left in voicemail is automatically forwarded by MMS), which is a real pain. While I can keep reminding my wife to enter even just one letter in the Subject field of her iPhone so that I can receive her messages, I cannot force T-Mobile Poland to do so and I just can’t receive my voicemail MMS at all.

  • I have to manually resize images (e.g. taken by the camera) to be able to send them. It is impossible to just take a photo and send it like on any other phone where I guess they’re automatically resized, it takes opening the image in some image processing app and manually shrinking its size first. Which is an even bigger pain.

  • Installing @slava’s “MMS Settings” (and choosing the 1 MB file size limit) improved things a little bit. Now I can send larger images (I guess up to that 1 MB limit) and if the image is too large there is simply an error that “the MMS couldn’t be sent” (and there’s an MMSC error code in the logs), whereas before installing “MMS Settings” and applying those changes messages with images larger than a few hundred kB or so were just stuck on “Sending” with the spinning wheel rotating eternally.

It’s been months like that. And it’s one of the reasons why I still don’t dare to make SFOS my daily driver and I keep switching to my trusty BlackBerry Passport whenever I need to truly rely on my phone.

1 Like

Sorry it took forever. I’ve finally filed a PR for that:

9 Likes

That’s a really great news! So, if I understand it correctly, it is now closer to being included in one of the future OS updates, right?

Thank you very much @slava.

1 Like