Support for closing WebRTC data channels as described in RFC
8831 (section 6.7) now fully supported. This means that we can now
reuse data channels that have been closed properly. Previously, an
application that created a lot of short-lived on-demand data channels
would quickly exhaust resources held by lingering non-closed data
channels.
We now use a one-to-one style socket interface to SCTP just like the
Google implementation (i.e. SOCK_STREAM instead of SOCK_SEQPACKET, see
RFC 6458). For some reason the socket interface to use was made
optional through a property "use-sock-stream" even though code wasn't
written to handle the SOCK_SEQPACKET style. Specifically the
SCTP_RESET_STREAMS command wouldn't work without passing the correct
assocation id. Changing the default interface to use from
SOCK_SEQPACKET to SOCK_STREAM now means we don't have to bother about
the association id as there is only one association per socket. For
the SCTP_RESET_STREAMS command we set it to SCTP_ALL_ASSOC just to
match the Google implementation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2186>
- Do not send ABORTs for unexpected packets are as response to INIT
- Enable interleaving of messages of different streams
- Configure 1MB send and receive buffer for the socket
- Enable SCTP_SEND_FAILED_EVENT and SCTP_PARTIAL_DELIVERY_EVENT events
- Set SCTP_REUSE_PORT configuration
- Set SCTP_EXPLICIT_EOR and the corresponding send flag. We probably
want to split packets to a maximum size later and only set the flag
on the last packet. Firefox uses 0x4000 as maximum size here.
- Enable SCTP_ENABLE_CHANGE_ASSOC_REQ
- Disable PMTUD and set an maximum initial MTU of 1200
Calling bind() only sets up some data structures and calling connect()
only produces one packet before it returns. That packet is stored in a
queue that is asynchronously forwarded by the encoder's source pad loop,
so not much is happening there either. Especially no waiting is
happening here and no forwarding of data to other elements.
This fixes a race condition during connection setup: the connection
would immediately fail if we pass a packet from the peer to the socket
before bind() and connect() have returned.
This can't happen anymore as bind() and connect() have returned already
before both elements reach the PAUSED state, and in webrtcbin there is
an additional blocking pad probe before the decoder that does not let
any data pass through before that anyway.
The library is thread-safe by itself and potentially calls back into our
code, not only from the same thread but also from other threads. This
can easily lead to deadlocks if we try to hold our mutex on both sides.
And free data with the correct free() function in the receive callback
by passing it to gst_buffer_new_wrapped_full() instead of
gst_buffer_new_wrapped().
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
On Windows, if libusrsctp and gstreamer are built with different
C runtimes (CRT), we cannot free memory allocated inside libusrsctp
with the `free()` function from gstreamer's CRT.
`usrsctp_freedumpbuffer()` simply calls `free()`, but because of the
way DLLs work on Windows, it will always call the free function from
the correct CRT.
This change makes it possible to create more than just 5 webrtc
data channels. The maximum number of data channels is exactly
DEFAULT_NUMBER_OF_SCTP_STREAMS / 2, therefore the limit is now
512.
