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 <[email protected]> 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
[email protected]
https://lists.ofono.org/mailman/listinfo/ofono
