• 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 54.9k 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.
    • L Offline
      lduboeuf
      last edited by 4 Nov 2020, 08:52

      Another question, should Ubports still maintain nuntium instead of moving to a more mainstream mms service ( if any ) ?

      K 1 Reply Last reply 5 Nov 2020, 18:15 Reply Quote 0
      • J Offline
        jezek @lduboeuf
        last edited by 5 Nov 2020, 17:12

        Progress report:

        @lduboeuf said in The MMS lost story:

        The ubports-qa will not help you build it locally.

        Yes, I know that. I just wanted to see, what it does. It uses apt command to install packages. The package is compiled on a server to a deb package.

        So, the build process for nuntium is described in repos ./debian/ folder. Upon investigation I figured out it installs only 2 files. A binary to /usr/bin/nuntium and /usr/share/upstart/sessions/nuntium.conf which is an config for upstart.

        The binary nuntium can be compiled from the repos ./cmd/nuntium/ folder using GOOS=linux GOARCH=arm go build command on notebook and then can be copied and replace the file on phone.

        If I want to replace and use the new nuntium binary on the phone, first the currently running process has to be stopped using initctl stop nuntium. Then replace binary and start process (initctl start nuntium).

        The logs in ~/.cache/upstart/nuntium.log say, that the new (by me on notebook builded) binary is running. This means, I can compile, replace & run nuntium. The bug hunt can start.

        jEzEk

        L 1 Reply Last reply 5 Nov 2020, 17:54 Reply Quote 0
        • L Offline
          lduboeuf @jezek
          last edited by lduboeuf 11 Jun 2020, 09:39 5 Nov 2020, 17:54

          @jezek nice :). I don't understand how do you build the deb though, which command ?.
          [Edit]: ok re-read your post 😉

          So the defered download feature is not a bug, but never get implemented. Nuntium should be aware of the current situation e.g: if cellular-data is off or mms auto retrieval is off and notify upper layer with a special flag that there is a pending MMS before trying to get the MMS context from ofono. ( you can see where it happens in my PR ).
          Nuntium should thus provide a callable method via dbus to fetch the MMS.

          1 Reply Last reply Reply Quote 1
          • K Offline
            Keneda @lduboeuf
            last edited by 5 Nov 2020, 18:15

            @lduboeuf
            If something as good as, or better, exists, and is more "up to date", why not...

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

            1 Reply Last reply Reply Quote 0
            • L Offline
              lduboeuf
              last edited by 6 Nov 2020, 22:35

              @jezek can be interesting to have: https://github.com/ubuntu-phonedations/nuntium/commit/57e4ecda2c1363daa69eb56cf962ff2fd4589bff

              J 1 Reply Last reply 7 Nov 2020, 02:09 Reply Quote 0
              • J Offline
                jezek @lduboeuf
                last edited by 7 Nov 2020, 02:09

                @lduboeuf said in The MMS lost story:

                @jezek can be interesting to have: https://github.com/ubuntu-phonedations/nuntium/commit/57e4ecda2c1363daa69eb56cf962ff2fd4589bff

                Yep, I know about that. Before any new changes I have to rewrite all imports from "ubuntu-phonedations" to "ubpors". Because of that I diffed the repo to see if everything matches and found the same code as you. Everything will be in explained in my next PR. Work in progress. 😉

                jEzEk

                L 1 Reply Last reply 7 Nov 2020, 16:34 Reply Quote 2
                • L Offline
                  lduboeuf @jezek
                  last edited by 7 Nov 2020, 16:34

                  @jezek Awesome,

                  Also i had confirmation that the code from phonedation is the last work from Canonical.

                  J 1 Reply Last reply 7 Nov 2020, 22:01 Reply Quote 0
                  • J Offline
                    jezek @lduboeuf
                    last edited by 7 Nov 2020, 22:01

                    @lduboeuf Just made a PR, the code is in there.

                    jEzEk

                    1 Reply Last reply Reply Quote 2
                    • J Offline
                      jezek
                      last edited by 8 Nov 2020, 14:37

                      It would be nice to test the PR mentioned above, so it can be merged and I can focus on furher development. I have tested it only by replacing the nuntium binary. The ubports-qa method should be tested too (what should be the right command for the PR?). Write the test results to the PR comment, or here. Thank you all.

                      Note: I did a MMS quick test (if it's working) by sending an MMS to myself. The test was successful, but I did get about 10 notifications upon delivery. Can anybody confirm, please?

                      jEzEk

                      L 1 Reply Last reply 8 Nov 2020, 16:21 Reply Quote 0
                      • L Offline
                        lduboeuf
                        last edited by 8 Nov 2020, 15:59

                        @jezek
                        I will test tomorrow. The command is sudo ubports-qa install PR_nuntium_5 .

                        Thanks for making it 😉

                        1 Reply Last reply Reply Quote 0
                        • L Offline
                          lduboeuf @jezek
                          last edited by 8 Nov 2020, 16:21

                          @jezek so can't wait finally, see PR comment ;-). If you want your PR to be reviewed, did you set a reviewer ? But don't be stuck if not merged ( sometimes it takes few months ^^...), just add a PR as a draft that is rebased from your PR 5.

                          I didn't found any issues, thanks.a lot.

                          1 Reply Last reply Reply Quote 1
                          • J Offline
                            jezek
                            last edited by 10 Nov 2020, 20:48

                            @lduboeuf said in The MMS lost story:

                            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.

                            jEzEk

                            L 1 Reply Last reply 10 Nov 2020, 23:05 Reply Quote 1
                            • L Offline
                              lduboeuf @jezek
                              last edited by lduboeuf 11 Oct 2020, 23:24 10 Nov 2020, 23:05

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

                              1 Reply Last reply Reply Quote 1
                              • J Offline
                                jezek
                                last edited by 1 Dec 2020, 15:54

                                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.

                                jEzEk

                                L 1 Reply Last reply 2 Dec 2020, 12:49 Reply Quote 1
                                • Josele13J Offline
                                  Josele13
                                  last edited by 1 Dec 2020, 20:45

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

                                  Xiaomi Redmi Note 9 pro
                                  Oneplus Nord 100
                                  Xiaomi Redmi Note 7
                                  Nexus 5
                                  Bq E4.5 Ubuntu edition .... is dead

                                  1 Reply Last reply Reply Quote 0
                                  • L Offline
                                    lduboeuf @jezek
                                    last edited by lduboeuf 12 Feb 2020, 12:55 2 Dec 2020, 12:49

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

                                    1 Reply Last reply Reply Quote 1
                                    • L Offline
                                      lduboeuf
                                      last edited by 3 Dec 2020, 07:22

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

                                      1 Reply Last reply Reply Quote 1
                                      • J Offline
                                        jezek
                                        last edited by jezek 13 Dec 2020, 14:46

                                        Failed MMS redownload progress report:

                                        There are now 3 drafts on github:

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

                                        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.

                                        jEzEk

                                        FlaF L 2 Replies Last reply 13 Dec 2020, 17:41 Reply Quote 5
                                        • FlaF 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
                                            • First post
                                              Last post