If a QMI modem doesn't support the deprecated DMS_UIM_GET_IMSI command,
use the UIM_READ_TRANSPARENT command to read EFimsi on the SIM to
determine the IMSI.
If a QMI modem doesn't support the deprecated DMS_UIM_GET_ICCID command,
use the UIM_READ_TRANSPARENT command to read EFiccid on the SIM to
determine the ICCID.
This patch adds a mm_bcd_to_string() helper function to convert a byte
array representing a binary-coded decimal (BCD) number to a string
representing the equivalent decimal number.
In preparation of deprecating the SubscriptionState property in the
Modem3gpp interface, this CL updates the altair-lte plugin to update the
Pco property in the Modem3gpp interface upon receiving %PCOINFO
notification.
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.
