In this case network changes will not be detected.
Additionally fall back to binding on all network interfaces (in this case a user
will have problems when using multiple network interfaces, but there is really
not much we can do without a functioning CallsNetworkWatch).
This would mean we're failing when Calls is started with all NICs not connected
or disabled. To make matters worse this would only be fixable by restarting
Calls.
Otherwise we might miss the IP of the remote peer leaving us unable to
establish a connection for RTP.
From https://datatracker.ietf.org/doc/html/rfc4566#section-5.7
A session description MUST contain either at least one "c=" field in
each media description or a single "c=" field at the session level.
It MAY contain a single session-level "c=" field and additional "c="
field(s) per media description, in which case the per-media values
override the session-level settings for the respective media.
The assumption that the IP of the remote peer can always be found in the
sdp_connection member of the sdp_session_s struct does not always hold true
and we should handle this case gracefully (i.e. without crashing).
As it's not guaranteed that the home directory is always writable
during the build. Debspawn for example does not allow this
and we might get such a warning:
`CallsSipProvider-WARNING **: 21:58:14.839: Failed to create directory '/home/salsaci/.config/calls': 13`
The libsofia-sip stack needs to bind to a specific interface when there are
multiple network interfaces available.
Handles should be recreated when the default route changes.
This makes sure all of the supported protocols have a chance of working.
Since nua_set_params does not update NUTAG_URL (carefully rechecking the docs
verifies this), it is safe to remove the code in update_nua().
However, this means that we will have to recreate the nua stack,
which incidentally is currently being worked on:
https://gitlab.gnome.org/GNOME/calls/-/merge_requests/402
secret_password_*_finish() may return FALSE without setting the GError.
F.e. trying to remove a non existent secret is not a failure.
The bug supposedly manifests itself because the updating account credentials
from the UI does not always seem to work correctly.
