Sofia detects a NAT by presence of the "received" parameter in the Via header in
the response to a REGISTER. Sofia will then update the Contact header to use the
IP as reported by the registrar.
The "received" parameter MUST be included in the response according to
https://datatracker.ietf.org/doc/html/rfc3261#section-18.2.1
when the registrar detects a difference between the domain part of the top Via
header and the packet source address but practice has shown that this will not
always be the case.
Addditionally this change allows us to have origins bound to different network
interfaces which would be useful when a registrar can only be accessed through a
VPN.
This also fixes an issue with SDP introduced in
36880c3d34 which was only seen on some SIP
providers:
The session name ("s=") line is not relevant for establishing a connection,
the connection data (c=") line is.
See https://datatracker.ietf.org/doc/html/rfc4566 section 5.3 and 5.7
Since we cannot do encrypted media streams yet, we should hardcode whether or
not we want to use SRTP to FALSE, so that sips target URLs can be used in SIP
calls at all.
If the origin is used for PSTN telephony extract the number from the
SIP dialstring (i.e. sip:+49160123456789@my-sip-host.de) and pass that
to call object for contact matching.
This let's us get rid of a lot of duplication in the derived classes.
Additionally we set the initial state to CALLS_CALL_STATE_INCOMING if
inbound is TRUE and CALLS_CALL_STATE_DIALING otherwise.
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).
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`
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.
