The MMS lost story

jezek

Currently nuntium even if Cellular-data is off try to fetch the mms and fail silently if any issue.
We would need to store the incoming WAP push notification, and propagate the issue to upper layer so that it can be tried later by user action.

I've studied the code a little bit, I now have a slight understanding of what nuntium does.

How do you imagine the deferred download? How does it work on other system (Android, iOS, …)?

My understanding is, that when nuntium gets MMS notification from ofono and the contend download fails (or deferred download is enabled), then nuntium stores the notification and sends info about the fail (or deliberate not downloading) with some identifier to the telepathy-ofono (like you said in quoted comment). It should also listen to telepathy-ofono, which could ask for downloading the content for some deferred MMS. Is this right (for starter)?

Note: I've seen the TODOs in the code and your PR which sends the fail message to telepathy-ofono, so I have a rough idea what to add or change, I'm just want to make sure I'm on the right track, before start.

lduboeuf

@jezek I think you have a better understanding after few hours than me in months

I don't have the whole picture, and not very comfortable about Dbus, Telepathy and such but yes i think you get the idea.

We could use something different than "received" as the status message like here: https://github.com/ubports/nuntium/blob/b43735b73d4bc549f98c9fe10a2bd56969761631/telepathy/service.go#L263
So that telepathy-ofono know that something either went wrong, or the MMS need to be downloaded with user interaction.
And yes a method to call to be able to download it.

jezek

Failed MMS in nuntium progress report:

I've begun a draft on nuntium github. There (or here?) we can talk what has to be done in other apps/packages to make it work satisfyingly.

I've build my code changes over @lduboeuf 's work on reporting lost MMS by sending empty message to telepathy-ofono. I've wondered, why the empty message, why not change status to "failed" (or other string)? I've got the answer as soon as I tried that. The message did not go through to messaging-app. Why? After reading some code, I've found out, that messages are sent from nuntium to tepepathy-ofono and then to the history-service, which saves the message to sqlite db, which then used by the messaging-app. I've not found out (yet) where the messages with unfamiliar status get lost, so let's stick to empty message as failed indication for now.

The new nuntium code works following way. When MMS download fails for some reason, the received mms notification with all info abut download is saved to storage before reporting the failed download (via empty message). Then we wait for user actions. Right now there are only 2 kind of actions comming to nuntium from messaging-app. A "mark read" and "delete" action. Only the "delete" action is handled and it deletes the MMS from nuntium storage. These 2 actions come right after another after a message is read (or thread deleted) in messaging-app. Right now, for testing, I've connected the MMS download retry to the "delete" request (which comes after message is read). In the future there should be a separate request name (like "redownload") and the failed message should send the "delete" request only after user delete action.

So for now the failed MMS will try to redownload after the empty message (failed warning) is read in messaging-app. To test the fail and redownload you can use nuntium-inject-push tool (if you don't won't to or can't use real MMS). I've added a flag there (--denial-count) to simulate failed downloads.

What has to be done (apart from I tidy up my code)?

find out how to send "redownload" request for failed message form messaging-app at user request.
prevent sending an "delete" request for failed message on message read in messaging-app
make it possible to report failed message using status, not an empty message.

Help, ideas, contributions or questions are welcome.

Josele13

Hi guys, I give an idea, I don't know if it's possible, I don't understand how MMS works on Ut

This is before that problem occurs.

Block MMS, until the mobile has good coverage it will not allow the download of the mms , put warning of Lack of coverage
When downloading the MMS, block the calls so that it does not hinder the download made, put a warning that the download of the mms is going to be made now.

the download is not done properly, then there is only the option of trying to download the mms again.

Regards...

lduboeuf

@jezek said in The MMS lost story:

Failed MMS in nuntium progress report:
I've begun a draft on nuntium github. There (or here?) we can talk what has to be done in other apps/packages to make it work satisfyingly.

Thank you for your implication

I've build my code changes over @lduboeuf 's work on reporting lost MMS by sending empty message to telepathy-ofono. I've wondered, why the empty message, why not change status to "failed" (or other string)? I've got the answer as soon as I tried that. The message did not go through to messaging-app. Why? After reading some code, I've found out, that messages are sent from nuntium to tepepathy-ofono and then to the history-service, which saves the message to sqlite db, which then used by the messaging-app. I've not found out (yet) where the messages with unfamiliar status get lost, so let's stick to empty message as failed indication for now.

Yes, i choosed not to modify the header, just to avoid any code change on telepathy-ofono and history-service, but i think this will be needed just to differentiate a MMS error to a MMS that need to be retrieved after user interaction

The new nuntium code works following way. When MMS download fails for some reason, the received mms notification with all info abut download is saved to storage before reporting the failed download (via empty message). Then we wait for user actions. Right now there are only 2 kind of actions comming to nuntium from messaging-app. A "mark read" and "delete" action. Only the "delete" action is handled and it deletes the MMS from nuntium storage. These 2 actions come right after another after a message is read (or thread deleted) in messaging-app. Right now, for testing, I've connected the MMS download retry to the "delete" request (which comes after message is read). In the future there should be a separate request name (like "redownload") and the failed message should send the "delete" request only after user delete action.
So for now the failed MMS will try to redownload after the empty message (failed warning) is read in messaging-app. To test the fail and redownload you can use nuntium-inject-push tool (if you don't won't to or can't use real MMS). I've added a flag there (--denial-count) to simulate failed downloads.
What has to be done (apart from I tidy up my code)?

find out how to send "redownload" request for failed message form messaging-app at user request.
prevent sending an "delete" request for failed message on message read in messaging-app

make it possible to report failed message using status, not an empty message.

Help, ideas, contributions or questions are welcome.

I think you already have the whole picture
So to add some precisions, messaging-app use telephony-service library as the middle man, this is where we can add a "redownload" method, but I won't be very helpfull for implementation details as i don't really know how to work with Telepathy framework.

Thanks again for your work ^ ^

Maybe, @sergiusens can give hints ? I know it is really hard to come back to a 5 years old project ^ ^

lduboeuf

@jezek
If you want to join me on Telegram: @lduboeuf or Matrix: @ldub:matrix.org for any discussion regarding that

jezek

Failed MMS redownload progress report:

There are now 3 drafts on github:

This is the first working version, where you can initiate re-download of failed MMS by clicking a button in messaging-app. This version is quirky and will be improved further.

What needs to be done?

make it possible to report failed message using status, not an empty message.
refactoring, tests, documentation, changelogs, etc...

Will report again on any noticable progress.

Fla

@jezek thank you very much for your work, this is a much needed feature.

lduboeuf

@jezek First thank you so much for working on that. I saw your draft on Nuntium/Telephony-service and messaging-app. I've tested it and it works ;-), can't wait for the full implementation, good luck.

How do you manage to propagate error or deferred status as Telepathy Message object to Telephony-service and History-service ?. By using the messageType , e.g: ChannelTextMessageTypeNotice ?https://telepathy.freedesktop.org/doc/telepathy-qt/a08524.html

jezek

Failed MMS re-download progress report:

Number of drafts on github is now 5:

https://github.com/ubports/nuntium/pull/8 - saves info about failed download, adds error & delete-event parameters (if needed) into dbus message for thelepathy-ofono and incoming re-download request.
https://github.com/ubports/telepathy-ofono/pull/20 - for received mms (from nuntium), parses additional parameters ("Error", "DeleteEvent") and sets Telepathy message headers accordingly ("x-ubports-error", "supersedes").
The "supersedes" header indicates, that the current message replaces the one stored in the header and is currently handled by history-service without any change. (Note: during injection testing, history service fails to delete the supersedes message, if it is in another conversation)
The "x-ubports-error" header should indicate an error message when message propagates through telepathy-qt to history-service. Maybe the error propagation could be done via "delivery-status", "delivery-error", "delivery-error-message" headers and no changes in history-service will be needed (theory needs testing).
https://github.com/ubports/history-service/pull/35 - the code here does nothing new yet, just adds some logging. The idea is to change status if "x-ubports-error" is set. It's possible, that this PR will be unnecessary.
https://github.com/ubports/telephony-service/pull/20 - adds methods to propagate re-download request to nuntium.
https://github.com/ubports/messaging-app/pull/260 - adds re-download button to error message.

The redownload should work after these PRs. The new thing is, that after hitting redownload the old error message bubble should be deleted when the new message arrives (as successfully received message or new error message).

What needs to be done:

improve error mms logic (currently: when delivered message is empty, without attachments). The idea is, that a delivered message is an error message when message is empty (historical reasons) or status is one of MessageStatusPermanentlyFailed, MessageStatusTemporaryFailed or MessageStatusPending. The message, which can be re-downloaded will have temporaryFailed status and will show the re-download button. Upon re-download clicked the state will be changed to pending (the re-download button is disabled). When re-download is not possible (expired, some other error) the status will be permanentlyFailed or empty message (current).
set status in history-service (if needed)
refactoring, tests, documentation, changelogs, etc...

I'm sorry, I'm so slow with progress, have only cca a hour a day for coding/testing. And building, deploying, phone restarting and log/code studying takes too much time. I hope it'll get faster.

@lduboeuf said in The MMS lost story:

How do you manage to propagate error or deferred status as Telepathy Message object to Telephony-service and History-service ?. By using the messageType , e.g: ChannelTextMessageTypeNotice ?

I'm afraid, that propagating via messageType (declaring new type) could break some other logic, which handles message type. So I decided to go with custom header "x-ubports-error". Or maybe using other headers (see above).

Questions, ideas or critics are welcome.

Edit: https://github.com/ubports/telepathy-ofono/pull/20 and https://github.com/ubports/history-service/pull/35 fail to pass checks. Does anyone know why?

AppLee

@jezek said in The MMS lost story:

I'm sorry, I'm so slow with progress

Don't be sorry, you're infinitely faster than one that does nothing.
Thank you very much for your time and trouble.

lduboeuf

@jezek said in The MMS lost story:

I'm afraid, that propagating via messageType (declaring new type) could break some other logic, which handles message type. So I decided to go with custom header "x-ubports-error". Or maybe using other headers (see above).

You're right, good point

Questions, ideas or critics are welcome.

No suggestions, i think you have all the stack well ( But i'm not a master of that part )

Edit: https://github.com/ubports/telepathy-ofono/pull/20 and https://github.com/ubports/history-service/pull/35 fail to pass checks. Does anyone know why?

Some work is done regarding infrastructure, maybe @Flohack can give the reasons.

Awesome work!

jezek

Failed MMS re-download progress report:

This week was no significant progress. Just pushed some commits to nuntium. All of them make changes in nuntuim testing tool nuntium-inject-push. Changes mainly allow to modify the sender of the test MMS (resp. MMS notification) via the --sender (resp. --sender-notification) flag.

jezek

Failed MMS re-download progress report:

The progress is slow, but steady. Two PR drafts got updated:

What was updated:

Some refactoring was done in telephony-service in redownloadMesage pathway (the function now needs 3 string parameters instead of a string map).
The redownload (in telephony-service) changes message status to pending before sending a redownload request to nuntium.
The redownload (in telephony-service) sends redownload request to nuntium only if message status is unknown (later it will be other status) to not request redownload more times than needed (if function is called more times)
Redownload buton gets disabled if message status is other than unknown (will be other status later), to indicate hat redowload is in progress.

jezek

Failed MMS redownload progress report:

Following PR's got some updates:

https://github.com/ubports/telepathy-ofono/pull/20 - set delivery-status header to indicate error message
https://github.com/ubports/history-service/pull/35 - set TemporarilyFailed status to error message. Before this, the status was default (unknown) and the error message was identified by empty message & attachment fields for incoming message. From now on, we can identify an error message by status and we can use the message & attachment fields to identify the error & other info (expire, ...) in future.
https://github.com/ubports/messaging-app/pull/260 - The error message text & redownload button (visibility, enabled) depend on message status. The redownload button gets disabled right after click, for more responsible feeling.
https://github.com/ubports/telephony-service/pull/20 - only redownload error messages with TemporarilyFailed status.

lduboeuf

@jezek Awesome, will test as soon ubports-qa be more stable

jezek

Failed MMS redownload progress report:

Because of unsafe apt operations, which makes crossbuilder & ubports-qa unsafe too, I've redirected my attention to nuntium, resulting in some commits to https://github.com/ubports/nuntium/pull/8. (Note: I can easily deploy nuntuim to phone without apt)

What was done?

My operator (and other?) resends multimedia message notifications ever 10 minutes, if notification is not marked as received. This resulted in new error message (when download fails) and notification sound every time. These new commits prevents this behavior.

Every notification comes with transaction-id, which is stored on download error and if new notification comes with the same transaction-id and there was a download error again, the error message will not be sent to telepathy again.

The only caveat is, that if the second download fails on another error as the first, then the second error will not be communicated (however no error description is communicated now, this will be added in future). I'll see, if this will need attention later.

To test these changes easier, I've added an transaction-id flag to nuntium-inject-push testing tool.

That's all for this week, see ya next time.

lduboeuf

@jezek Qt5.12 is devel ready since few hours, you can start update and continue to play with ubports-qa & crossbuilder.

For the notification being resent by the provider, this is not the case for me at least.

Thanks again for your implications

jezek

Failed MMS redownload progress report:

This week only nuntium PR got updated.

There was a problem with redownload after nuntium got restarted. After nunium restarted (on crash, or phone reboot), the redownload button from messaging-app didn't work. This was because of the button sends the redownload request to nuntium through dbus. And after nuntium restart, there was no one listening on dbus for the redownload signal. I've fixed this by spawning listeners for messages on modem identification. So the redownload now works even after phone restart.

Also the nuntium-inject-pust testing tool got update. It can now autodetect the end-point flag from nuntium logs using grep & sed commands.

Keneda

What a massive work done on this thread, @lduboeuf @jezek the masters of MMS

Hope for the work ready for OTA16, but no rush here, take the time you need.