The MMS lost story

AppLee

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

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.

lduboeuf

@keneda said in The MMS lost story:

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

Now you can delete my name, jezek is doing all the stuff

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

I doubt it will, am i right @jezek ?

Keneda

@lduboeuf
What would'd be Don Quichotte without Sancho Panza

Not a problem if not in OTA16.

jezek

@lduboeuf said in The MMS lost story:

@keneda said in The MMS lost story:

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

I doubt it will, am i right @jezek ?

hmm... I think I'm near end. There are 3-4 tasks to do till end. But sometimes a task is done 1-2 new emerge My guess, if everything goes smooth, 1 month.

lduboeuf

@jezek btw, can you add an empty commit or any piece of code to trigger build on telepathy-ofono and history-service ? They are still marked as failed and thus not accessible with ubports-qa

jezek

@lduboeuf said in The MMS lost story:

@jezek btw, can you add an empty commit or any piece of code to trigger build on telepathy-ofono and history-service ? They are still marked as failed and thus not accessible with ubports-qa

Done

lduboeuf

@jezek Can you sync with xenial branch for those 2 repos, JenkinsFile have been updated and should fix the build issue

jezek

@lduboeuf said in The MMS lost story:

@jezek Can you sync with xenial branch for those 2 repos, JenkinsFile have been updated and should fix the build issue

Done

lduboeuf

@jezek oups, still messaging-app to be built again...
So i am almost ready to test it
sudo ubports-qa list:

PR_nuntium_8 PR_telepathy-ofono_20 PR_telephony-service_20 PR_history-service_35 PR_messaging-app_260

lduboeuf

@jezek so fetch your messaging-app to test. It seems to work well ;-).

Do you differentiate a download Error with a "Cellular-data off" state ?
For the "data-off", it could be a simple message like on other platforms with a "Download" button.

Awesome work

jezek

@lduboeuf said in The MMS lost story:

@jezek oups, still messaging-app to be built again...

messaging-app updated

@lduboeuf said in The MMS lost story:

Do you differentiate a download Error with a "Cellular-data off" state ?
For the "data-off", it could be a simple message like on other platforms with a "Download" button.

In the code nuntium returns an error on first connection attempt (there are more stages), but I really don't know if different kind of trouble will cause different error type. I can assume, that if an error happens after first connection attempt, it is not cause of "Celular-data off" state. And I really don't have an idea, how to cause different cause of errors. The plan is to send the error text and/or type to messaging-app via the error message. Maybe then, we will spot the pattern. Meanwhile you can investigate (if you want) and try to cause & get some non "Cellurae-data off" error and then see the log (code producing download errors is here). Maybe, if we can't differentiate by error message, nuntium could ask someone on dbus, or see the config, what the state of cellular switch is and make a note about it in the error message.

Btw, I don't know how are other platforms are handling mms download errors.