introduce `calls_sip_media_manager_get_capabilities ()` which takes
a GList of MediaCodecInfo's as input to generate a SDP message.
If using in an SDP answer we simply feed it a list of the common codecs
as gathered from the SDP offer.
static capabilities are now supporting multiple codecs and generate correct SDP
messages. This only relates to SDP offers. When we are answering an offer we
must take the offer from the other party into account when creating the answer.
Hence why we differentiate between "static" and "dynamic" (not implemented yet)
capability strings.
by making sure the call-added signal is emitted early enough
so that all consumers (display, ringer, etc) have a chance of getting
notified when the call state changes from f.e. DIALING to DISCONNECTED
similar to how its done in 03d960ccaf
for the dummy provider.
* removed nua_callstate_authenticating as it was never hit
* move debug statement further up, because we might not reach it if no
corresponding call is found
* handle 401 and 407 the same way
note: we should record which realm we're authenticating against during
REGISTER so we can prompt the user for additional credentials when
challenged for a different realm - still happens when calling from
a sip.linphone.org account to a jmp.bwapp.bwsip.io account.
IPv6 should work, but sofia's outbound engine keep printing
errors involving the outbound engine. Working theory:
Failing ICMPv6 (pings) can make sofia think we don't have connectivity.
Note that we also don't get any answers from the SIP servers we tried so far.
And adapt to changes
It's easier to track changes if we are using GListModel than
a GList. Also, eventually we shall have multiple providers,
and we can use GtkFlattenListModel to merge multiple origins
without manually managing pointers ourself.
Since several widgets has APIs to handle GListModels, it will
also help us create widgets from GListModels easily.
The 'property-changed' and 'disconnect-reason' signals weren't disconnected on the
voice_call object cleanup, and callbacks would thus still be fired once a second
call happens, resulting in a crash.
Signed-off-by: Eugenio Paolantonio (g7) <me@medesimo.eu>
This fixes this two issues:
- Emit the events origin-removed, origin-added when required.
- Remove call immediately when disconnected and emit events:
By using `g_idle_add ()` we can't be sure when the call is actually
removed and could stay potentionaly for evere, as long the main loop is
busy. This can lead to unexpected behavior. If the calls shouldn't be
freed then it's required to increase the ref count. This is similar how
the `remove` event works in a `GtkContainer`.
This is part of a larger refactoring effort, with the goal to replace
all the get_*() member functions in provider abstraction interfaces with
GObject properties. See also: https://source.puri.sm/Librem5/calls/issues/6
How `g_type_class_peek ()` was used it didn't return the correct parent
class in most cases.
G_DEFINE_TYPE macro creates a pointer we can use to get the parent
class `n_p_parent_class`.
Because we didn't use the correct parent class the object initialisation
wasn't fully completed for some GtkWidgets.
See https://developer.gnome.org/gobject/stable/chapter-gobject.html#gobject-instantiation
for more information.
This commit makes use of the `n_p_parent_class pointer` created for this
specific use case where ever possible.
Fixes: https://source.puri.sm/Librem5/calls/issues/118
Clean up the disconnect messages so they make sense when presented to
the user. Also add new state change reasons from ModemManager 1.10
and 1.12.
Fixes#90
We want to remove the modem if the currently removed interface is
Voice. It was previously removing the device if the removed
interface wasn’t Voice.
Fixes https://source.puri.sm/Librem5/calls/issues/94
This actually makes sense in the mapping; the only time an MM call is
in MM_CALL_STATE_UNKNOWN is when it's an outgoing call that hasn't
been started. It also helps avoid a lot of needless issues dealing
with the Calls call state.
This is an initial, static implementation of plugins. The
CallsApplication has a plugin name which can be changed with a new
--provider command line option. This plugin name is used to
instantiate the appropriate plugin when the application is activated.
From then on, the plugin cannot change.
In future, we can expand this support to include loading multiple
plugins at once, configurable through some UI. This will have
far-reaching implications though, and complicate things like
enumerating the provider hierarchy. There is also no practical
benefit right now; the mm and ofono plugins can't be used at the same
time because ModemManager and oFono don't play nice together, and the
whole raison d'être of the dummy plugin is undermined if you can make
use of one of the others. So for now, we just implement one static
plugin.
