| Age | Commit message (Collapse) | Author |
|---|
|
We want to ensure that all errors reported via DBus operations are
normalized to MM-specific errors.
We don't want to return QMI or MBIM specific errors, as those are
protocol specific and we don't want DBus clients to need to rely on
knowing which is the protocol in use by the device.
|
|
../src/mm-iface-modem-voice.c: In function ‘mm_iface_modem_voice_reload_all_calls’:
../src/mm-iface-modem-voice.c:2549:64: warning: passing argument 2 of ‘((MMIfaceModemVoice *)g_type_interface_peek((void *)((GTypeInstance *)self)->g_class, mm_iface_modem_voice_get_type()))->load_call_list’ from incompatible pointer type [-Wincompatible-pointer-types]
2549 | reload_all_calls_ready,
| ^~~~~~~~~~~~~~~~~~~~~~
| |
| void (*)(MMIfaceModemVoice *, GAsyncResult *, GTask *) {aka void (*)(struct _MMIfaceModemVoice *, struct _GAsyncResult *, struct _GTask *)}
../src/mm-iface-modem-voice.c:2549:64: note: expected ‘GAsyncReadyCallback’ {aka ‘void (*)(struct _GObject *, struct _GAsyncResult *, void *)’} but argument is of type ‘void (*)(MMIfaceModemVoice *, GAsyncResult *, GTask *)’ {aka ‘void (*)(struct _MMIfaceModemVoice *, struct _GAsyncResult *, struct _GTask *)’}
|
|
Enable AT URCs for calls on top of QMI Voice indications
for AT+QMI devices only. Some AT+QMI devices send unreliable
QMI indications when the host is resuming. In such cases,
AT URCs can be used as a fall back to make calls reliable.
While AT+QMI devices relied before on AT commands to load
call list information and handle AT URCs for async updates,
this is now handled through QMI by forcefully reloading the
call list instead of processing the AT URCs.
This approach is disabled by default through the
MM_IFACE_MODEM_VOICE_INDICATION_CALL_LIST_RELOAD_ENABLED property.
This property is set to true in case of QMI modems.
|
|
|
|
If an incoming call is detected during the CLCC polling, the polling
timeout will already be set, so don't assert when checking the polling
id afterwards, just make sure we don't reset the timeout.
https://lists.freedesktop.org/archives/modemmanager-devel/2020-May/007866.html
|
|
|
|
The BroadMobi BM818 can time out with +CLCC calls. When this happens,
active calls are terminated due to reporting an empty list. To fix
this, we only report the call list if the +CLCC didn't result in an
error.
|
|
If a call is missing from the +CLCC call list and terminated because
of that, add a debugging statement to log the call details.
|
|
Outgoing calls which ring before the first +CLCC response cannot match
on the direction/state and are terminated, at least on the BroadMobi
BM818. For example:
<debug> 1 calls being established: call list polling required
<debug> (ttyUSB1) device open count is 3 (open)
<debug> (ttyUSB1): --> 'AT+CLCC<CR>'
<debug> (ttyUSB1): <-- '<CR><LF>+CLCC: 1,1,0,1,0,"",128<CR><LF>+CLCC: 2,0,3,0,0,"07763578094",129<CR><LF><CR><LF>OK<CR><LF>'
<debug> Reported 2 ongoing calls
<debug> call at index 1: direction incoming, state active, number n/a
<debug> call at index 2: direction outgoing, state ringing-out, number 07763578094
<info> Call state changed: dialing -> terminated (unknown)
<warn> unexpected incoming call to number 'n/a' reported in call list: state active
<warn> unexpected outgoing call to number '07763578094' reported in call list: state ringing-out
To fix this, we match calls in a +CLCC call list by number as
well.
|
|
mm-iface-modem-voice.c: In function ‘interface_disabling_step’:
mm-iface-modem-voice.c:2589:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
2589 | ctx->step++;
| ~~~~~~~~~^~
mm-iface-modem-voice.c:2591:5: note: here
2591 | case DISABLING_STEP_DISABLE_UNSOLICITED_EVENTS:
| ^~~~
...
|
|
mm-iface-modem-voice.c: In function ‘in_call_setup_context_step’:
mm-iface-modem-voice.c:1863:5: error: switch missing default case [-Werror=switch-default]
1863 | switch (ctx->step) {
| ^~~~~~
...
|
|
mm-iface-modem-voice.c: In function ‘prepare_hold_and_accept_foreach’:
mm-iface-modem-voice.c:804:5: error: enumeration value ‘MM_CALL_STATE_UNKNOWN’ not handled in switch [-Werror=switch-enum]
804 | switch (mm_base_call_get_state (call)) {
| ^~~~~~
...
|
|
The error returned in support_check_finish() should be treated as
optional, as in all the other optional feature interfaces.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/172
|
|
|
|
|
|
The supported voice features may be different before and after SIM-PIN
unlock, so do not cache the result of the support check operation.
|
|
This new flag allows users of the API to know whether general purpose
voice calls are allowed or otherwise only voice calls to the
registered emergency numbers should be performed.
ModemManager won't really do any distinction between emergency and
non-emergency calls at this point, this flag is just an early
indication for the user of the API that no normal voice call should be
attempted.
|
|
|
|
We're going to allow emergency calls at any point, so prepare the call
list handling logic during initialization, not when the modem is first
enabled.
|
|
If the full list reporting includes calls in terminated state (e.g. on
modems managed by the Simtech plugin), then ignore those no longer
known to us, because it just means that they have already been
processed.
<debug> [1571060859.227759] (ttyUSB2): <-- '<CR><LF>+CLCC: 1,0,6,0,0,"639335936",129<CR><LF>'
<debug> [1571060859.227890] Reported 1 ongoing calls
<debug> [1571060859.227913] call at index 1: direction outgoing, state terminated, number 639335936
<debug> [1571060859.227946] call info matched (matched direction/state no, matched index yes, matched terminated no) with call at '/org/freedesktop/ModemManager1/Call/1'
<debug> [1571060859.227963] state updated: terminated
<info> [1571060859.227978] Call state changed: dialing -> terminated (unknown)
<debug> [1571060859.228173] (ttyUSB3): <-- '<CR><LF>+CLCC: 1,0,6,0,0,"639335936",129<CR><LF>'
<debug> [1571060859.228234] Reported 1 ongoing calls
<debug> [1571060859.228251] call at index 1: direction outgoing, state terminated, number 639335936
<warn> [1571060859.228274] unexpected outgoing call to number '639335936' report2ed in call list: state terminated
|
|
|
|
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).
|
|
The GSM supplementary services related changes, as well as the rework
done to manage calls per call id, is copyrighted by Purism SPC.
|
|
|
|
|
|
|
|
If the URC reporting the DTMF does not specify the call index,
mark it as received in all active ones.
|
|
Instead of providing a method to exclusively provide incoming call
updates, make it more generic so that we allow plugins to provide
state updates for any kind of call, not just incoming ones.
The logic to match the call info provided by URCs is updated so that
it can be reused also by the single call reports, in addition to the
full call list reports.
|
|
We cannot handle in-call state at call level because the state may
apply to multiple active calls at the same time:
* the modem is in-call if there is at least one ongoing call (>=1).
* the modem is not in-call if there are no ongoing calls (==0).
The new logic implements call state monitoring for all available call
objects, and whenever the state of one or more calls change, we'll go
over all of them to see how many of the calls can be considered to be
ongoing (i.e. not terminated, not unknown). If we have at least one
call ongoing, we'll setup the in-call state and otherwise, we'll clean
it up.
Setting up and cleaning up the in-call state involves unsolicited
message and audio channel settings management operations.
|
|
|
|
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 terminate all ongoing calls.
|
|
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.
|
|
If the modem supports call list polling, we'll setup a timeout to poll
for the full call list periodically, in order to get detailed call
states.
The timeout is setup as soon as a new call is created, and it will be
kept enabled as long as there is a call being established (i.e. not
unknown, not terminated, not active).
|
|
E.g. as per the AT+CLCC output.
|
|
|
|
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.
|
|
Try to automatically detect when the caller finishes the attempt to
establish the call.
|
|
The mm_gdbus_call_set_() methods update the properties in the same way
as via g_object_set(), no need to do it twice.
|
|
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.
|
|
To have proper ordering in the D-Bus signals, the skeleton's property
changes must be flushed before the Call{Add,Delet}ed signals are
emitted. Without this flush, the emission of the PropertiesChanged
signal is delayed until the main loop is idle. This causes problems
on the client side, for example the CallAdded signal being received
before the Calls property contains the call.
Closes: #81
|
|
The mm_call_list_add_call() takes a full reference to the call, so we
can unref the original one safely.
|
|
|
|
|
|
|
