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.
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
Shuffle the code around and make use of docstrings to conform to
the newly introduced coding style as described in `HACKING.md`
This commit also introduces docstrings describing each source file.
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.
