Support keeping network-initiated USSD messages for a longer period of time.
USSD messages can be user-initiated or network-initiated. ModemManager supports user-initiated USSD messages, but it (at least mmcli
) (apparently currently) does not (reliably) support network-initiated USSD messages. However, for a user experience comparable with other mobile phones, reliable support for network-initiated USSD messages is necessary.
For example, a mobile phone network provider may offer to interact with the user by asking the user to initiate a USSD message with code *123#
. If the user sends such a USSD message, then the network provider may respond with a menu. If the user then answers (e.g. 3
, with the meaning to select item 3 from the menu), then the network provider may release the USSD session and then initiate another USSD message to the user which contains an answer to the menu item selection to the user.
Currently, ModemManager seems to ignore these network-initiated USSD messages. (However, in --debug
mode, ModemManager's QMI code prints ignoring unprocessed USSD message:
, along with the body of the network-initiated USSD message. However, this is not satisfactory, because it is not shown to the user through GUI applications and because it is impossible to send an answer to this sub-menu.)
More precisely, it seems that ModemManager, upon receiving a network-initiated USSD message, actually calls
mm_iface_modem_3gpp_ussd_update_network_notification (MM_IFACE_MODEM_3GPP_USSD (self), utf8);
but for some reason, this network notification seems to be immediately overwritten, such that mmcli --3gpp-ussd-status
never (or almost never) sees the network notification, making it unusable.