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