The $GNGGA traces provide "combined" values when multiple satellite
constellations are used (e.g. GPS+GLONASS). Prefer these values over
the GPS-only $GPGGA traces if both are received.
USB sticks only support voice if ^CVOICE returns 0. And to enable audio
streaming on the "Application" port (whatever is returned by AT^DDSETEX=?)
we need to send AT^DDSETEX=<port> after starting the call. After that
the serial port will send and accept signed 16-bit 8000hz PCM audio, or
whatever format is returned by ^CVOICE?.
This patch is a rework of the original implementation by:
Dan Williams <dcbw@redhat.com>
Modems that require specific commands to setup or cleanup the audio
channel as soon as a call is ongoing can subclass these two new
methods.
The setup() method is considered part of the call start/accept
process, and so if it fails, the whole operation will fail.
The failures in the cleanup() method will be reported in the log, but
otherwise ignored, as this operation may be executed without any
user intervention (e.g. if the remote party hangs up).
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>
