Hi Wajdi,

On 02/14/2019 04:49 AM, wajdi zairi wrote:
Hi all ,

We are planning to add a feature to handle sent SMS status . The available OFONO APIs to use seems provided by *org.ofono.Message* but when i made some tests to catch the *PropertyChanged* signal on a sent SMS i notes that the result is always "sent" (when out from TX) even on a wrong destination number .

Can you elaborate? If the destination number is still a valid number, then this wouldn't be surprising.

# signal sender=:1.12 -> dest=(null destination) serial=105 path=/gemalto_0/message_2F3426EAC5E3EBA365FA626347886C0EC4DC5323; interface=org.ofond
    string "State"
    variant       string "sent"

Also the call of *org.ofono.Message.GetProperties*() on given message object path will fail since ofono is removing to object after sending (sms_tx_queue_remove_entry) .

Yes, this is expected behavior and somewhat documented in the messagemanager-api.txt. However, D-Bus API is not meant to be used for tracking message history; in fact delivery reports are not even signaled via D-Bus. This is on purpose, since we cannot easily guarantee any sort of reliability via any IPC mechanism, and implementing a protocol between a history client (using acks or other mechanisms) over D-Bus was deemed to be too complicated. The history plugin is probably what you want.

So here the "sent" means that the message was treated and out from TX but does not give the real state if it was delivered or not . I made a try by adding History driver to our Gemalto drivers and it gives a better result regarding SMS delivery status which meet our requirements.

I'm guessing using status reports?

To keep our ofono aligned with latest ofono updates, we want to upstream our contributions so i want to get your opinion about a propasal upstream candidate :

- Add history driver implementation to drivers/gemaltomodems/

Why would SMS history be specific to Gemalto modems?

- Add signal in plugins/gemalto.c  to notify the different sent messages status  (indicated on enum*ofono_history_sms_status* )
- Then the signal can be consumed by any client after sending an SMS .

The reason why we don't have such an API is already covered above. Ideally, you want the history plugin to directly update the history in your database of choice, or simply call your call/sms history tracking service directly. There's really no reason to broadcast this information via a different API.

ofono mailing list

Reply via email to