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.
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.
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 ‘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)) {
| ^~~~~~
...
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.
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).
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 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).
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.
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
Aleksander Morgado
Dylan Van Assche
Bob Ham
Ben Chan
Marco Bascetta