Hi Denis, Thank you for your reply !
I thought using the sms history as a driver under drivers/gemaltomodems/ but i agree with you that using as plugin will be better since it is not specific to Gemalto modems and already designed as plugin in Examples . Please correct me because like i understood that you don't prefer using DBus to notify sms status while Ofono is already exposing Dbus interfaces for methods calls or signals and built around Dbus . I tried to keep using Dbus to signal sms reports status from added History plugin. Signaling such status will avoid to keep saving/handling SMS reports on Ofono side and let applications/clients handle this based on returned SMS ID when sending . Yes , I'm enabling Delivery Reports (*org.ofono.MessageManager.SetProperty string:"UseDeliveryReports" variant:boolean:"true"* ) *Here a result using proposed sms history plugin : * Here i sent an SMS : ~# org.ofono.MessageManager.SendMessage string:"xxxxxx" string:"hello"o_0 method return sender=:1.22 -> dest=:1.33 reply_serial=2 object path "/gemalto_0/message_9BD77FFD695EB2F234B255257C1A372D2C4582F9" Here i monitor on added "smsStatusUpdate" member for added interface "org.ofono.smsHistory" (*dbus-monitor --system "type='signal',interface='org.ofono.smsHistory'" & *) ~# signal sender=:1.22 -> dest=(null destination) serial=1651 path=/gemalto_0; interface=org.ofono.smsHistory; member=smsStatuse array [ dict entry( string "SmsId" variant string "9BD77FFD695EB2F234B255257C1A372D2C4582F9" ) dict entry( string "Status" variant uint16 1 => OFONO_HISTORY_SMS_STATUS_SUBMITTED ) ] signal sender=:1.22 -> dest=(null destination) serial=1655 path=/gemalto_0; interface=org.ofono.smsHistory; member=smsStatusUpdate array [ dict entry( string "SmsId" variant string "9BD77FFD695EB2F234B255257C1A372D2C4582F9" ) dict entry( string "Status" variant uint16 4 => OFONO_HISTORY_SMS_STATUS_DELIVERED ) ] *Here when using wrong number : * # signal sender=:1.22 -> dest=(null destination) serial=2337 path=/gemalto_0; interface=org.ofono.smsHistory; member=smsStatusUpdate array [ dict entry( string "SmsId" variant string "63D3C903B5EED7B41D3E666CA53A3200D5E14F23" ) dict entry( string "Status" variant uint16 1 ) ] signal sender=:1.22 -> dest=(null destination) serial=2341 path=/gemalto_0; interface=org.ofono.smsHistory; member=smsStatusUpdate array [ dict entry( string "SmsId" variant string "63D3C903B5EED7B41D3E666CA53A3200D5E14F23" ) dict entry( string "Status" variant uint16 5 => OFONO_HISTORY_SMS_STATUS_DELIVER_FAILED ) ] Please let me know your opinion and suggestions. Kind Regards, Wajdi ZAIRI Embedded Software Engineer Le jeu. 14 févr. 2019 à 18:07, Denis Kenzior <denk...@gmail.com> a écrit : > 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. > > Regards, > -Denis >
_______________________________________________ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono