There are a large number of files in the tree that define _GNU_SOURCE
despite not actually using features hidden behind this flag. This patch
removes all these definitions in one fell swoop...
Typically responses to USSD requests are coming with status
zero (NOTIFY) but some are coming with status 2 (TERMINATED).
If those contain data, the data should be presented to the user.
... when a USSD notification is received. Some networks
send 0 (no further user action required) after the response
timeout expires. That should result in the user input form
getting removed from the ME screen.
This patch was generated by the following semantic patch
(http://coccinelle.lip6.fr/)
// <smpl>
@fix disable is_null,isnt_null1@
expression *E;
@@
- !E
+ E == NULL
// </smpl>
The logic of valid_ussd_string was not quite correct as it didn't take
care of size 1 USSD strings. In addition, call_in_progress parameter is
passed in to take care of size 2 USSD strings which might start with a
'1' according to the rules of 22.030.
The comment about USSD routing is removed, it is out of scope of oFono.
The cellular network routes the USSD requests based on the rules laid
out in the 22.090, however, any string that can be encoded according to
the rules of 23.030 is valid USSD.
Send SS requires Call Forwarding / Call Settings / Call Barring to check
whether USSD is currently busy. If it is, then the SIM should be
notified appropriately.
We introduce a function __ofono_ussd_is_busy to help with this.
When the user sends a response, the network can still continue the
dialog, it is not a final response and we cannot transition to an idle
state when the command finishes. Instead we set it back to a special
state and treat subsequent network responses as unsolicited.
This adds the methods on the D-bus interface to allow the
client to handle USSD requests from the network, according to 22.090.
Unfortunately this document is not clear on every point and some
details can't be implemented. This includes reporting unsupported
request to the network, unsupported language, ME busy etc, because
there isn't an AT command for that.
If the network requests user action in the response to an MO USSD, we
cannot immediately return to USSD_STATE_USER_IDLE. Instead,
USSD_STATE_USER_ACTION is entered.
Note that it is left up to the driver to notify() when the USSD
transaction is closed by the network due to inactivity. Another way to
return to USSD_STATE_IDLE is for the user to cancel() the transaction.
The registration was done by using the storage in the modem. Refactored
to use the new atom watch APIs and storing the control entries in the
ussd atom itself
Denis Kenzior
Jonas Bonn
Slava Monich
John Ernberg
Philippe Nunes
Lucas De Marchi
Henrique Dante de Almeida
Marcel Holtmann
Jeevaka Badrappan
Pekka Pessi
Yang Gu
Andrzej Zaborowski
Aki Niemi
Denis Kenzior