| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
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.
|
|
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.
|
|
signal with 'SendDtmf' and 'DtmfReceived'
|
|
|
|
|
|
|
|
|
