• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
UBports Robot Logo UBports Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

The MMS lost story

Scheduled Pinned Locked Moved OS
133 Posts 16 Posters 55.0k Views 6 Watching
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F Offline
      Fla @jezek
      last edited by 13 Dec 2020, 17:41

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

      1 Reply Last reply Reply Quote 1
      • L Offline
        lduboeuf @jezek
        last edited by lduboeuf 14 Dec 2020, 22:40

        @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

        1 Reply Last reply Reply Quote 1
        • J Offline
          jezek
          last edited by jezek 20 Dec 2020, 21:37

          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?

          jEzEk

          A L 2 Replies Last reply 21 Dec 2020, 08:31 Reply Quote 4
          • A Offline
            AppLee @jezek
            last edited by 21 Dec 2020, 08:31

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

            1 Reply Last reply Reply Quote 3
            • L Offline
              lduboeuf @jezek
              last edited by 21 Dec 2020, 12:33

              @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!

              1 Reply Last reply Reply Quote 1
              • J Offline
                jezek
                last edited by 27 Dec 2020, 21:49

                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

                1 Reply Last reply Reply Quote 0
                • J Offline
                  jezek
                  last edited by jezek 1 Mar 2021, 21:23 3 Jan 2021, 21:23

                  Failed MMS re-download progress report:

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

                  • https://github.com/ubports/telephony-service/pull/20
                  • https://github.com/ubports/messaging-app/pull/260

                  What was updated:

                  1. Some refactoring was done in telephony-service in redownloadMesage pathway (the function now needs 3 string parameters instead of a string map).
                  2. The redownload (in telephony-service) changes message status to pending before sending a redownload request to nuntium.
                  3. 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)
                  4. Redownload buton gets disabled if message status is other than unknown (will be other status later), to indicate hat redowload is in progress.

                  jEzEk

                  1 Reply Last reply Reply Quote 4
                  • J Offline
                    jezek
                    last edited by 10 Jan 2021, 20:46

                    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.

                    jEzEk

                    L 1 Reply Last reply 10 Jan 2021, 21:46 Reply Quote 2
                    • L Offline
                      lduboeuf @jezek
                      last edited by 10 Jan 2021, 21:46

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

                      1 Reply Last reply Reply Quote 0
                      • J Offline
                        jezek
                        last edited by 17 Jan 2021, 20:53

                        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.

                        jEzEk

                        L 1 Reply Last reply 18 Jan 2021, 22:07 Reply Quote 4
                        • L Offline
                          lduboeuf @jezek
                          last edited by 18 Jan 2021, 22:07

                          @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

                          1 Reply Last reply Reply Quote 0
                          • J Offline
                            jezek
                            last edited by 24 Jan 2021, 22:19

                            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.

                            jEzEk

                            J 1 Reply Last reply 31 Jan 2021, 21:05 Reply Quote 5
                            • K Offline
                              Keneda
                              last edited by 25 Jan 2021, 12:54

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

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

                              2015-2023 : Meizu MX4 ☠️⚰️✝️
                              2023-2024 : Nexus 5 ☠️⚰️✝️
                              2024-***** : FPOS Fairphone 5 waiting UT for freedom 😉
                              🇲🇫🇬🇧

                              L 1 Reply Last reply 25 Jan 2021, 13:39 Reply Quote 1
                              • L Offline
                                lduboeuf @Keneda
                                last edited by 25 Jan 2021, 13:39

                                @keneda said in The MMS lost story:

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

                                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 ?

                                K J 2 Replies Last reply 25 Jan 2021, 13:55 Reply Quote 0
                                • K Offline
                                  Keneda @lduboeuf
                                  last edited by Keneda 25 Jan 2021, 13:55

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

                                  Not a problem if not in OTA16.

                                  2015-2023 : Meizu MX4 ☠️⚰️✝️
                                  2023-2024 : Nexus 5 ☠️⚰️✝️
                                  2024-***** : FPOS Fairphone 5 waiting UT for freedom 😉
                                  🇲🇫🇬🇧

                                  1 Reply Last reply Reply Quote 1
                                  • J Offline
                                    jezek @lduboeuf
                                    last edited by 25 Jan 2021, 16:16

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

                                    jEzEk

                                    L 1 Reply Last reply 25 Jan 2021, 17:58 Reply Quote 1
                                    • L Offline
                                      lduboeuf @jezek
                                      last edited by 25 Jan 2021, 17:58

                                      @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

                                      J 1 Reply Last reply 25 Jan 2021, 22:32 Reply Quote 1
                                      • J Offline
                                        jezek @lduboeuf
                                        last edited by 25 Jan 2021, 22:32

                                        @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

                                        jEzEk

                                        L 1 Reply Last reply 26 Jan 2021, 14:45 Reply Quote 0
                                        • L Offline
                                          lduboeuf @jezek
                                          last edited by 26 Jan 2021, 14:45

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

                                          J 1 Reply Last reply 26 Jan 2021, 15:59 Reply Quote 1
                                          • J Offline
                                            jezek @lduboeuf
                                            last edited by 26 Jan 2021, 15:59

                                            @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

                                            jEzEk

                                            L 1 Reply Last reply 26 Jan 2021, 16:22 Reply Quote 1
                                            53 out of 133
                                            • First post
                                              53/133
                                              Last post