IPv4 keeps working through the magic of IPv4 mapped IPv6 addresses.
Without this change errors about invalid address family will be raised
when trying to connect to a IPv6 host.
Bail out! CallsSipMediaPipeline-FATAL-WARNING: Error on the message bus: Could not get/set settings from/on resource. (../gst/udp/gstmultiudpsink.c(1228): gst_multiudpsink_configure_client (): /GstPipeline:media-pipeline/GstUDPSink:rtcp-udp-sink:
Invalid address family (got 10))
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019292
Plugins could no longer be found because we installed the plugins
outside the search path:
The directory structure uses singular 'provider', not plural
'providers'.
Fixes 11ba83c16e
Since we will introduce another type of plugin for the policy engine
we want to have each plugin type in separate directories.
We also have to adjust:
- plugin search directories
- po file location
- update paths for calls-doc target
Bail out! CallsSipMediaPipeline-FATAL-WARNING: Error trying to setup codecs for pipeline: Could not create 'decoder' element of type avdec_g722
stderr:
(gst-plugin-scanner:196349): GLib-GObject-WARNING **: 07:29:24.149: type name '-a-png-encoder-pred' contains invalid characters
See
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1055
This avoids the following warning:
../plugins/sip/calls-sip-origin.c: In function ‘sip_r_register’:
../plugins/sip/calls-sip-origin.c:483:26: warning: the comparison will always evaluate as ‘true’ for the address of ‘m_url’ will never be NULL [-Waddress]
483 | if (sip->sip_contact && sip->sip_contact->m_url && sip->sip_contact->m_url->url_host) {
| ^~
In file included from /usr/include/sofia-sip-1.12/sofia-sip/nua.h:47,
from ../plugins/sip/calls-sip-util.h:28,
from ../plugins/sip/calls-sip-call.h:30,
from ../plugins/sip/calls-sip-origin.c:31:
/usr/include/sofia-sip-1.12/sofia-sip/sip.h:477:23: note: ‘m_url’ declared here
477 | url_t m_url[1]; /**< SIP URL */
| ^~~~~
../plugins/sip/calls-sip-origin.c: In function ‘sip_callback’:
../plugins/sip/calls-sip-origin.c:779:23: warning: the comparison will always evaluate as ‘true’ for the address of ‘a_url’ will never be NULL [-Waddress]
779 | if (sip->sip_from && sip->sip_from->a_url &&
| ^~
/usr/include/sofia-sip-1.12/sofia-sip/sip.h:386:22: note: ‘a_url’ declared here
386 | url_t a_url[1]; /**< URL */
| ^~~~~
This enables proper negotiation of the codec when answering calls, which
previously also responded with codecs that were not part of the users
preferred ones.
Fixes: #413
A property of type SipMediaEncryption is added to both the origin and
the call which allows to state if we want the media session to be
encrypted with SRTP.
Logic is added to interact with the CallsSdpCryptoContext if encryption
is desired.
Objects of this type keep track of SDP of the local and remote peers,
allow generating offers and answers and codify default policy used for
cryptographic parameters.
Allows setting up cryptographic parameters with
calls_sip_media_pipeline_set_crypto() and use them to set GstCaps for
GstSrtpDec and GObject properties for GstSrtpEnc
by adding functions to the public API which determine if state changes
should be shown to the user and use them (instead of duplicating similar
logic).
We only have a single source of settings, so we should reflect that by
using a singleton. This also reduces our LoC.
This doesn't impair our ability to run tests because there we run with
GSETTINGS_BACKEND=memory
The rtpbin will request GstSrtpDec and GstSrtpEnc elements using the
"request-{rtp,rtcp}-{de,en}coder" family of signals.
The newly added boolean use_srtp controls whether the srtp elements are
returned in the signal handler and thus decides if SRTP is used or not.
Ust GST_DEBUG_BIN_TO_DOT_FILE to generate a dot graph of a pipeline for
debugging purposes when SIGUSR2 is received.
Note the same signal is also used within the dummy plugin to simulate an
incoming call from an unknown number, so when testing you probably want either
the sip plugin or the dummy plugin, but not both.
We were using two distinct pipelines, one for receiving and one for
sending. The receive pipeline was set to the playing state to allocate
the sockets which we would reuse for the sending direction for our NAT
traversal scheme.
The rework to a single pipeline broke reusing sockets subtly.
This happened because the state of the GstUDPSrc could be reset leading
to newly allocated sockets once the pipeline is set to play.
This is now fixed by locking the state of the GstUDPSrc in the ready
state during socket reuse setup and while the pipeline is paused.
Additionally get rid of the "close-socket" property on the udp sources
because it was never needed.
Fixes aa446f82
sq
Using a single pipeline makes implementing encryption easier because we don't
need to duplicate srtpenc and srtpdec elements for each direction.
It also makes it easier to switch to using farstream down the line (see #426).
If the environment variable GST_DEBUG_DUMP_DOT_DIR is set, a graph of the send
and receive pipelines will be written to disk.
To generate a png from the exported dot files graphviz can be used like this:
`dot -Tpng -oimage.png graph.dot`
Now that initialization is split per pipeline and that the OS handles port
allocation we can move setting up socket reuse into the pipeline initialization
step instead of setting it up when starting the media pipelines.
This makes the calls_sip_media_pipeline_start() method a bit simpler.
We're also now reusing sockets for RTCP.
Closes#315
We're not setting the desired ports from the outside anymore, but rather
querying the ports that have been allocated by the operating system.
Therefore the lport-rtp and lport-rtcp property have become superfluous and are
being removed. We also adapt to changes outside of the pipeline code.
We don't expect the initialization to be able to fail. The only thing that could
potentially fail is setting up codecs and this has been delayed until after
initialization.
First of we get rid of the bindings between from "lport-rtp" and "lport-rtcp" to
the "port" property of the udpsrc elements. The properties themselves will get
removed a little later as the required changes are rather intrusive and we need
some more infrastructure in place before we can do the switch.
This is the first step in getting rid of the requirement to have the codec set
during object construction. The goal is to have pipelines prepared in advance so
that the codec can be plugged in once negotiation is complete.
Having the pipelines prepared in advance let's us grab allocated local ports of
udpsrc elements for RTP and RTCP instead of setting those and hoping they're not
yet in use.
The id property will be used to keep track of which origin was used for a call,
so that we can default to reusing the same origin when placing a call from the
history.
Fixes the deprecation warning from meson:
DEPRECATION: target sip links against shared module sip, which is incorrect.
This will be an error in the future, so please use shared_library() for sip instead.
If shared_module() was used for sip because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
This makes running tests harder as we cannot call gst_init() after gst_deinit()
has been called.
This is what the API reference has to say about it at
https://gstreamer.freedesktop.org/documentation/gstreamer/gst.html?gi-language=c#gst_deinit
It is normally not needed to call this function in a normal application as the
resources will automatically be freed when the program terminates. This function
is therefore mostly used by testsuites and other memory profiling tools.
It isn't needed in the implementation either. It was only useful because it
included system headers like sys/types.h and sys/socket.h which we should now
include directly.
This will make it easier to move the media manager into the core sources.
Introduce a state-changed signal which also gives a reason for why the state
changed. This will allow the UI to give some meaningful feedback to the user.
Additionally we can get rid of a number of things that were not really states,
but rather reasons for why a state changed (f.e. authentication failures).
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`
