Storage behaviour when sending SMS

[Aleksander Morgado]

Hey,

> while trying to resolve the issue when sending SMS with specific mbim modems (https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/562), I see different behaviour when sending SMS depending on the modem I use:
>
> When I send an SMS using a non-MBIM modem (UBlox Toby L210, RNDIS), the SMS is shown (using mmcli) as sent. When I then restart ModemManager, the SMS is no longer there. So it seems that the message is not stored in SIM or modem.
> When I send an SMS using my MBIM modem (Telit LE910C1-EU), the SMS is shown (using mmcli) as sent. When I then restart ModemManager, the SMS is still there. So it seems that the message is stored immediately when sending (to be precise: Any attempt to send the SMS creates an entry in the SMS storage on this modem -- so when I have three attempts to send an SMS, two failed and the third succeeded, I have two drafts and on sent message in the storage (!?) )
>
> Is ModemManager capable to handle both of these scenarios? It seems to me that ModemManager does not expect the second scenario, which leads to the issue when deleting messages...
>

The SMS management in the MBIM protocol is extremely bad. There is no
notion of SMS storages or no action to explicitly store SMS messages.
Any SMS management operation on devices using the MBIM protocol
exclusively is really far from ideal.

I have considered in the past modifying the logic so that all SMS
management operations are done via AT commands when an AT port is
available in the MBIM device, as that would allow us to be
full-featured again in this regard. This is something that could
benefit all MBIM devices out there, so a really nice thing to do IMO.
If anyone is up to the task, let me know and I'll provide some
guidance on what should be done.

> (BTW: In both cases, ModemManager crashes when I try to store the message using mmcli after it has been sent).
>

Ohh, that's something to fix definitely. Could you open a new issue in
gitlab? We should not crash, we should return an error cleanly.

-- 
Aleksander