[GH-ISSUE #11] The status of message delivery

kerem commented

2026-02-28 01:22:43 +03:00

Owner

Originally created by @saratovout on GitHub (Feb 6, 2012).
Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/11

Originally assigned to: @mandric on GitHub.

I wish that was added to the information on the status of message delivery.

Originally created by @saratovout on GitHub (Feb 6, 2012). Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/11 Originally assigned to: @mandric on GitHub. I wish that was added to the information on the status of message delivery.

kerem closed this issue

2026-02-28 01:22:43 +03:00

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@eyedol commented on GitHub (Aug 17, 2012):

@ashowtimes I'm looking into this. Could you give more details. It sounds a bit vague

@eyedol commented on GitHub (Aug 17, 2012): @ashowtimes I'm looking into this. Could you give more details. It sounds a bit vague

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@saratovout commented on GitHub (Aug 18, 2012):

@eyedol I would like to be able to know the status of delivery previously sent sms messages.

@saratovout commented on GitHub (Aug 18, 2012): @eyedol I would like to be able to know the status of delivery previously sent sms messages.

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@ghost commented on GitHub (Aug 22, 2012):

Not sure if this is what was meant, but I would like to have an ability to pass delivery notifications onto the server.

For example, with response like

{
    "payload": {
        "success": "true",
        "task": "send",
        "messages": [
            {
                "to": "+000-000-0000",
                "message": "Important message" ,
                "confirm_delivery_key": "736b6d90-ec4e-11e1-aff1-0800200c9a66"
            },
            {
                "to": "+000-000-0000",
                "message": "Not so important message" 
            },
        ]
    }
}

SMSSync would note that when it received the delivery report for the first message, it would make a POST to the sync URI with:
confirm_delivery_key = 736b6d90-ec4e-11e1-aff1-0800200c9a66
secret = well, your secret
timestamp = time of delivery, or the delivery report.

Or maybe send periodically as a json list the UUID:s that have gotten delivery confirmations since the last update to reduce amount of traffic as there probably wouldn't be a need to get each message's delivery confirmation immediately upon arrival. (In my use case it would result in a few hundred requests within minutes, and I'm definitely not in such a hurry, even though I want to know if someone never gets my messages, or sometimes maybe if a time-critical message hasn't been delivered before a due time.)

@ghost commented on GitHub (Aug 22, 2012): Not sure if this is what was meant, but I would like to have an ability to pass delivery notifications onto the server. For example, with response like ``` json { "payload": { "success": "true", "task": "send", "messages": [ { "to": "+000-000-0000", "message": "Important message" , "confirm_delivery_key": "736b6d90-ec4e-11e1-aff1-0800200c9a66" }, { "to": "+000-000-0000", "message": "Not so important message" }, ] } } ``` SMSSync would note that when it received the delivery report for the first message, it would make a POST to the sync URI with: _confirm_delivery_key_ = 736b6d90-ec4e-11e1-aff1-0800200c9a66 _secret_ = well, your secret _timestamp_ = time of delivery, or the delivery report. Or maybe send periodically as a json list the UUID:s that have gotten delivery confirmations since the last update to reduce amount of traffic as there probably wouldn't be a need to get each message's delivery confirmation immediately upon arrival. (In my use case it would result in a few hundred requests within minutes, and I'm definitely not in such a hurry, even though I want to know if someone never gets my messages, or sometimes maybe if a time-critical message hasn't been delivered before a due time.)

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@saratovout commented on GitHub (Aug 22, 2012):

2 @agenttihirvinen, @eyedol:

In the other direction. Interested in is about "text message delivery report".
As far as I know in the Andoid this parameter is called "PendingIntent".

array (
  'secret' => '',
  'from' => '111',
  'message' => 'Hello!!',
  'message_id' => '51',
  'sent_timestamp' => '05-08-12 13:02',
  'sent_to' => '12345',
  'status' => 'DELIVERED'
)

@saratovout commented on GitHub (Aug 22, 2012): 2 @agenttihirvinen, @eyedol: In the other direction. Interested in is about "text message delivery report". As far as I know in the Andoid this parameter is called "PendingIntent". ``` css array ( 'secret' => '', 'from' => '111', 'message' => 'Hello!!', 'message_id' => '51', 'sent_timestamp' => '05-08-12 13:02', 'sent_to' => '12345', 'status' => 'DELIVERED' ) ```

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@eyedol commented on GitHub (Aug 22, 2012):

I like this approach @ashowtimes approach as it will be easier to work with' Just giving a status delivery message would be much easier to work with than generating a long confirmation string.

@eyedol commented on GitHub (Aug 22, 2012): I like this approach @ashowtimes approach as it will be easier to work with' Just giving a status delivery message would be much easier to work with than generating a long confirmation string.

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@eyedol commented on GitHub (Aug 26, 2012):

I'll look into this more in the next release...

@eyedol commented on GitHub (Aug 26, 2012): I'll look into this more in the next release...

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@ghost commented on GitHub (Sep 11, 2012):

The message ID for a message that originated on the sync server is useless to it because the ID is generated on the phone, so the server has no knowledge of it. Receiving such a delivery report, the server would have to compare the whole message text against its message database along with the number the message was sent to.

With a server-generated delivery confirmation key, SMSsync would only have to store that particular key-message pair and then pass the key string/number back onto the sync server upon receiving a delivery notification for that message.

(How does the delivery report identify the message it concerns? And how exactly is this supposedly unique message_id generated? I thought first that they might be useful for identifying a message, but I was quickly proven wrong, seeing now a whopping 18 distinct ids among hundreds of messages)

@ghost commented on GitHub (Sep 11, 2012): The message ID for a message that originated on the sync server is useless to it because the ID is generated on the phone, so the server has no knowledge of it. Receiving such a delivery report, the server would have to compare the whole message text against its message database along with the number the message was sent to. With a server-generated delivery confirmation key, SMSsync would only have to store that particular key-message pair and then pass the key string/number back onto the sync server upon receiving a delivery notification for that message. (How does the delivery report identify the message it concerns? And how exactly is this supposedly unique message_id generated? I thought first that they might be useful for identifying a message, but I was quickly proven wrong, seeing now a whopping 18 distinct ids among hundreds of messages)

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@mandric commented on GitHub (Dec 11, 2013):

+1 Any updates on this? I would also like to get delivery confirmation back to the server if the feature is available on the mobile network. I'm not very familiar with how delivery status feature works within Android or if there is some standard interface available when the feature is enabled on the mobile network. If anyone knows offhand what Android API to use for this please include here.

@mandric commented on GitHub (Dec 11, 2013): +1 Any updates on this? I would also like to get delivery confirmation back to the server if the feature is available on the mobile network. I'm not very familiar with how delivery status feature works within Android or if there is some standard interface available when the feature is enabled on the mobile network. If anyone knows offhand what Android API to use for this please include here.

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@eyedol commented on GitHub (Dec 17, 2013):

@mandric No update yet. There is an intent to know the status of an SMS delivery. See PendingMessages.java line #L92

@eyedol commented on GitHub (Dec 17, 2013): @mandric No update yet. There is an intent to know the status of an SMS delivery. See [PendingMessages.java line #L92](https://github.com/ushahidi/SMSSync/blob/develop/smssync/src/main/java/org/addhen/smssync/fragments/PendingMessages.java#L92)

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@eyedol commented on GitHub (Apr 10, 2014):

The spec doc lives here https://gist.github.com/mandric/10280606 You can follow the discussion.

@eyedol commented on GitHub (Apr 10, 2014): The spec doc lives here https://gist.github.com/mandric/10280606 You can follow the discussion.

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@eyedol commented on GitHub (Apr 22, 2014):

@eyedol the benefit of having a setting is SMSSync will generate less HTTP requests and the server will have less load. But thinking it's minor load that is generated.

I'm also thinking the delivery and sent values should get saved to the messages object as well, and can be displayed in SMSSync somewhere? No sense in throwing that information away if the server doesn't respond?

We can show them in the logs?

@eyedol commented on GitHub (Apr 22, 2014): > @eyedol the benefit of having a setting is SMSSync will generate less HTTP requests and the server will have less load. But thinking it's minor load that is generated. > > I'm also thinking the delivery and sent values should get saved to the messages object as well, and can be displayed in SMSSync somewhere? No sense in throwing that information away if the server doesn't respond? We can show them in the logs?

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@mandric commented on GitHub (Apr 22, 2014):

Sounds good, for now we can just log that information and maybe deal with saving/displaying it in SMSSync later. Also a setting will be required for this, I updated the doc.

@mandric commented on GitHub (Apr 22, 2014): Sounds good, for now we can just log that information and maybe deal with saving/displaying it in SMSSync later. Also a setting will be required for this, I updated the doc.

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@mandric commented on GitHub (Apr 25, 2014):

@eyedol extended this a bit https://gist.github.com/mandric/10280606 should be more robust now by adding extra polling for task=results and saving results data locally.

@mandric commented on GitHub (Apr 25, 2014): @eyedol extended this a bit https://gist.github.com/mandric/10280606 should be more robust now by adding extra polling for task=results and saving results data locally.

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@KamilKalfas commented on GitHub (Jul 21, 2014):

@mandric any update here ?

@KamilKalfas commented on GitHub (Jul 21, 2014): @mandric any update here ?

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@mandric commented on GitHub (Jul 21, 2014):

Sorry not yet. Were you planning to start on it? I was going to work on the server side of this one right?

@mandric commented on GitHub (Jul 21, 2014): Sorry not yet. Were you planning to start on it? I was going to work on the server side of this one right?

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@eyedol commented on GitHub (Aug 21, 2014):

@mandric anyway we could get an update on this? Would be great to have it in this release. It seems PR 7 can't be merged cleanly. Let me know how I can help.

@eyedol commented on GitHub (Aug 21, 2014): @mandric anyway we could get an update on this? Would be great to have it in this release. It seems [PR 7](https://github.com/mandric/SMSSync/pull/7) can't be merged cleanly. Let me know how I can help.

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@mandric commented on GitHub (Aug 21, 2014):

@eyedol I was supposed to test that weeks ago against an actual server implementation of the API. PR7 in my repo was really just a bookmark for myself to do this, still not done. We are working on our first beta release of the medic mobile desktop app which should happen next week and I can finally move on to some new things. @KamilKalfas reported that his implementation is complete according to the spec, and only needs review, testing and documentation. If you want to merge in the next release, I imagine he can fairly easily merge with dev and create a new clean PR and then we can discuss there further what should happen with this feature.

@mandric commented on GitHub (Aug 21, 2014): @eyedol I was supposed to test that weeks ago against an actual server implementation of the API. [PR7](https://github.com/mandric/SMSSync/pull/7) in my repo was really just a bookmark for myself to do this, still not done. We are working on our first beta release of the medic mobile desktop app which should happen next week and I can finally move on to some new things. @KamilKalfas reported that his implementation is complete according to the spec, and only needs review, testing and documentation. If you want to merge in the next release, I imagine he can fairly easily merge with dev and create a new clean PR and then we can discuss there further what should happen with this feature.

kerem commented

2026-02-28 01:22:44 +03:00

Author

Owner

@eyedol commented on GitHub (Aug 22, 2014):

@mandric I'm happy to merge this. I can extend the demo.php code on the SMSSync website to implement the changes so we can test with that. @KamilKalfas I'm happy to review what you've. Could you send a PR my way?

@mandric All the best with medic mobile desktop app's beta release.

@eyedol commented on GitHub (Aug 22, 2014): @mandric I'm happy to merge this. I can extend the demo.php code on the SMSSync website to implement the changes so we can test with that. @KamilKalfas I'm happy to review what you've. Could you send a PR my way? @mandric All the best with medic mobile desktop app's beta release.

Rows
Columns

[GH-ISSUE #11] The status of message delivery #8