So that we setup in-call events as soon as we get the incoming call
ringing in. This allows us to have plugin-specific implementations
e.g. reporting call termination when the remote caller hangs up.
Calls created from property bundles are always outgoing, while calls
created as input events from URCs during runtime are always incoming.
This change makes it mandatory to provide at least direction of the
call when the object is created, leaving the number as an optional
property that may or may not be known in advance (e.g. it would be
optional only for incoming calls).
The Voice interface logic must always use the create_call() object
from its own interface to create call objects, as that is the method
that plugins can subclass to provide plugin-specific call objects.
This applies to both incoming and outgoing calls.
Instead of handling the URCs in the modem object and using the
MMIfaceModem as a bridge to report the status read from the URC to a
call obtained from the MMCallList... just handle the URCs in the call
object itself.
In order to detect state changes while we're in-call, we have to
monitor the standard connection errors we're used to, but have them
processed as URCs instead of as responses to ATD requests.
The most detailed call state transition flow for a new outgoing call
would be:
UNKNOWN -> DIALING -> RINGING -> ACTIVE
But, if the modem doesn't support reporting intermediate states
(e.g. DIALING or RINGING) then a successful start() should imply
getting into ACTIVE state right away.
For now, only the Huawei plugin implements the detailed transition
support, so make them configurable via call object properties.
Don't do any call state update on the generic implementation of the
commands, do it in the common interface logic exclusively.
We were doing the state updates in both places.
Call information only lives in the ModemManager logic, there is no
associated date stored within the device itself. Therefore, simplify
everything by assuming there is nothing to remove.
Looks like this logic was implemented because it was originally based
on the SMS management logic, but for SMS we do have to remove
them (the stored PDU parts) from the device.
Make sure the async task is always finished, even when
mm_base_modem_at_command_finish() returns an error which is not
MM_SERIAL_ERROR_RESPONSE_TIMEOUT.
Don't return FALSE when call is successfully accepted, otherwise the
caller will get very confused:
ModemManager[19952]: <debug> [1528968478.344338] (ttyACM2): --> 'ATA<CR>'
ModemManager[19952]: <debug> [1528968478.361986] (ttyACM2): <-- '<CR><LF>OK<CR><LF>'
(ModemManager:19952): GLib-GIO-CRITICAL **: 11:27:58.387: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
And also, make sure the async task is always finished, even when
mm_base_modem_at_command_finish() returns an error which is not
MM_SERIAL_ERROR_RESPONSE_TIMEOUT.
Devices like the Netgear AC313U require explicit context monitoring,
otherwise the device may end up disconnected internally and MM would
still think that the connection is ongoing.
g_object_unref is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on
g_object_unref is thus not needed.
This prevents errors due to nasty typos in the strings.
We define all symbols in a single header file that is NOT considered
part of the API, as there is no need for MM clients to know about
these tags code-wise. These tags are only meaningful when associated
to devices in udev.
Information of each tag is included in the general API documentation.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/88
Some plugins or implementations (e.g. notably MBIM) may report a
single storage as supported and no way to update the current default
storage. In this specific case, we will initialize the default storage
to that single one supported right away, regardless of whether
selecting others is implemented or not.
E.g. China Mobile (MCC 460, MNC 0).
$ mmcli -m toby --location-get
/org/freedesktop/ModemManager1/Modem/0
-------------------------
3GPP location | Mobile country code: '460'
| Mobile network code: '0'
| Location area code: '6188'
| Cell ID: '40955'
-------------------------
GPS NMEA traces | Not available
-------------------------
Raw GPS | Not available
-------------------------
CDMA BS | Not available
Remove the redundant declaration of which slipped into the code in commit
091bf4dbd8 ("api: support location assistance data").
Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
The DW5821E module is managed in MBIM mode by default, and exposes a
NMEA capable tty in USB interface #4.
Enabling/disabling the NMEA output via the TTY is done with AT
commands, so this implementation requires also a valid AT port in the
system.
Given that the AT commands used to enable/disable this feature are
based on modifying non-volatile memory through AT^NV, this
implementation is very specific to the DW5821E. If we're able to do
the same on other Dell modules in the future, we'll just rename the
new object to a more generic one.
Aleksander Morgado
Dan Williams
Ben Chan
Thomas Haller
Ulrich Ölmann
Milo Casagrande
Paul Bartell