Ben Chan authored 6 years ago and Aleksander Morgado committed 6 years ago

g_match_info_free() already check if the given pointer is NULL and does
nothing on a NULL pointer.

Ben Chan authored 6 years ago and Aleksander Morgado committed 6 years ago

g_free() already check if the given pointer is NULL and does nothing on
a NULL pointer.

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.

Ben Chan authored 6 years ago and Aleksander Morgado committed 6 years ago

This patch fixes the following compiler warning:

mm-modem-helpers-qmi.c:568:5: error: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned int)' [-Werror,-Wimplicit-function-declaration]
    memset (extended_qmi_lte_bands, 0, extended_qmi_lte_bands_size * sizeof (guint64));
    ^

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).

Among other things, we now support:
  * Dialing to Ringing Out transition.
  * Ringing Out to Active transition.

Allow creating a new incoming call object also when we receive +CLIP,
so that we can have the remote caller number as soon as the object is
created.

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.

These are not used for anything, so just simplify code.

Totally equivalent to the default one in the MMBaseCall object.

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.

Try to automatically detect when the caller finishes the attempt to
establish the call.

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.

The mm_gdbus_call_set_() methods update the properties in the same way
as via g_object_set(), no need to do it twice.

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.

This will allow us to configure via mmcli devices that support LTE
bands that would not fit in the standard TLVs (e.g. band 66 below)
or bands which aren't really reported in the standard TLVs (e.g. bands
46 and 48 below).

  $ sudo qmicli -d /dev/cdc-wdm0 -p --dms-get-band-capabilities
  [/dev/cdc-wdm0] Device band capabilities retrieved:
      Bands: 'wcdma-2100, wcdma-pcs-1900, wcdma-1700-us, wcdma-850-us, wcdma-800, wcdma-900, wcdma-1700-japan, wcdma-850-japan'
      LTE bands: '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 38, 39, 40, 41, 42, 43'
      LTE bands (extended): '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30, 32, 38, 39, 40, 41, 42, 43, 46, 48, 66'