| Age | Commit message (Collapse) | Author |
|---|
|
Send each character through the state machine one at a time. Some
modems (various Quectel ones for example) can process multiple at
the same time, and while that should be easily implemented using
the new changes to send_dtmf() it's not done in any plugin yet.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Do what other dialers do and interpret ',' as a short pause, which
helps handle automated menus.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Generalize the timeout/stop logic that QMI requires into the
base call. We'll use this to implement the pause character (,)
generically.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Instead of hard-coding a 500ms DTMF tone duration, let applications
use a specific duration at call setup time.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Split out the things we actually use from MMBaseModem into
separate properties that can be independently implemented
(or just left NULL) for unit tests.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Continues removing usage of MMBaseModem in a bunch of files
by splitting out bits of its usage to separate interfaces.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
Rather than make all of them rely on MMBaseModem for it. This
lets us disentangle dependencies for easier unit testing.
For interfaces, rather than casting directly to MMBaseModem
use intermediate interfaces (MMIfaceAuth and MMIfaceOpLock)
that tests can fake out.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
|
|
When we don't care about the type of AT port to use, prefer the QMI or
MBIM based ones if any available.
|
|
The whole codebase is updated to assume the MMBaseModem AT operations
require an object implementing the MMIfacePortAt interface, instead of
a MMPortSerialAt object.
In the places where we know the port is a MMPortSerialAt, e.g. when we
query explicitly for the primary or secondary serial AT port, we will
use an explicit MM_IFACE_PORT_AT() cast when calling the AT command
method.
In the places where we get_best_at_port() we're going to assume that
we don't know the port type. This method will be updated in a follow
up commit to support the MMIfacePortAt interface as well.
|
|
|
|
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.
|
|
We're bumping the current "INFO" level messages to the new "MSG"
level, also making the new level the default.
The old "INFO" level will be used to setup an intermediate level of
logging which is not as verbose as "DEBUG" but still provides some
capabilities to analyze the behavior of a modem.
|
|
|
|
|
|
|
|
If the modem is connected using the primary port, we can just rely on
the secondary port.
# mmcli --call 0 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Connected: Cannot run sequence: port is connected'
|
|
|
|
|
|
If we get one of the in-call termination errors before ATD replies OK,
we need to cancel the start() operation right away and return an
error to the caller.
Otherwise, the Call will be reported as "terminated" right away, but
the caller would not get an error back until 90s later:
$ sudo mmcli --call 0 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Serial.ResponseTimeout: Serial command timed out'
|
|
The GSM supplementary services related changes, as well as the rework
done to manage calls per call id, is copyrighted by Purism SPC.
|
|
|
|
|
|
It will be set to TRUE if this call is part of a multiparty call.
|
|
The in-call unsolicited events and the in-call audio settings are
managed exclusively at modem level, and no longer at call object
level. This is because these two things are applicable to all calls
that may be active at the same time.
|
|
E.g. if we want the modem-level in-call state management to provide
what audio settings are expected in all ongoing calls.
|
|
|
|
This method allows deflecting an incoming or waiting call to a
different number.
|
|
E.g. we can hangup a waiting call without interfering with the active
one.
|
|
|
|
|
|
E.g. if the modem supports reporting incoming call updates explicitly.
|
|
|
|
|
|
The standard says a RING or CRING should be emitted whenever the
network sends an incoming call notification, which is nation-specific:
"Interpretation of indications from the network to determine what
constitutes a "ring" is defined by national regulations. This
result code should be repeated each time the network repeats the
incoming call indication." -- ITU-T Rec. V.250, p. 42
On the giffgaff (O2) network in the UK, a SIMCom SIM7100E modem emits
RING indicators every six seconds. The current timeout is only five
seconds resulting in a stream of timed-out ModemManager call objects
whenever there is an incoming call. To fix this, we increase the
timeout to ten seconds.
|
|
The handler assumes the regex sub-expressions each have the same index
so they need to be within the same set of parentheses rather than each
individually parenthesised. Without this fix, call state changes are
missed.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
