These new methods allow querying and updating the status of the call
waiting network service, as per 3GPP TS 22.083.
The status of the service is not a property because we don't want to
unconditionally load it on every boot, given that the process involves
talking to the network (i.e. it is not a device setting).
This method will join all active and held calls into a single
multiparty call, and then request the network to terminate the call on
the subscriber's end and transfer the control of the call to the
parties that are still in the call.
This method will put the currently active call on hold, and right away
accept the next available call.
The user of the API does not need to specify explicitly which is the
next call to accept, because that is decided automatically:
* If there is any waiting call, it will accept it right away.
* If there is no waiting call but there is a held call, it will make
the held call active again.
This method will hangup the currently active call and right away
accept the next available call.
The user of the API does not need to specify explicitly which is the
next call to accept, because that is decided automatically:
* If there is any waiting call, it will accept it right away.
* If there is no waiting call but there is a held call, it will make
the held call active again.
In addition to the standard human-friendly output, we now allow a
machine-friendly key-value pair output, much easier to parse and use
by programs that look at the mmcli output.
This new key-value pair output should be treated as API from now on, so
third-party programs can assume the output is compatible from one
release to another.
mmcli is GPLv2+; that's what --version has always said and that's what the
README in ModemManager sources specifies:
License.
The ModemManager and mmcli binaries are both GPLv2+.
The libmm-glib library is LGPLv2+.
