On the sink pad, we want the caps of the current stream, those
are the "received_caps" field. If we haven't received caps yet, then
we only care about the caps that the next element can accept, that is
the caps from the peer pad (and the preferences). Otherwise, we prevent
re-negotiation to a better codec when possible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2183>
Now intersect against pads on both sides if they are available.
If the intersection fails, we now just reject the creation of the offer
or answer as it means that the codec_preferences are too restrictive or
that the caps on both sides the webrtcbin are not compatible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2183>
When receiving an sctp message for a stream that not yet has an
sctpdec pad associated with it means we end up in
_on_sctpdec_pad_added. At this point we're holding the sctpassocation
lock. Then it's not possible to take the pc_lock because then code
executing under the pc_lock (which means anything in the webrtc
thread) may not take the sctpassociation lock. For example, running
the data channel close procedure from the webrtc thread means we
eventually end up sending a SCTP_RESET_STREAMS packet which needs to
grab the sctpassociation lock.
This means _on_sctpdec_pad_added simply cannot take the pc_lock and
also it is not possible to postpone the channel creation as we need to
link the pads right there. The solution is to introduce a more
granular dc_lock that protects only the things that needs to be done
to create the datachannel.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2186>
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>
First fail the offer creation if the mid of an existing offer doesn't
match a forced m-mline.
Then, for all newly added mlines, first look for a transceiver that
forces this m-line, then add a "floating" one, then the data channel.
And repeat this until we're out of transceivers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2104>
The simple case where this breaks is if you add a
datachannel and want to add a new pad (a new media) after). Another
case where this is broken is if the order of the media is forced to
something different by the peer.
It's more simple to just split both things completely. In practice, the
pads will be named in the order in which they are allocated, so it
shouldn't change the current behaviour, just enable new ones.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2104>
It was possible to generate a SDP that had an RTX payload type
that matched one of the media payload types when providing caps via
codec_preferences without any sink pads.
Fixes
m=video 9 UDP/TLS/RTP/SAVPF 96
...
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack pli
a=fmtp:96 apt=96
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2046>
default min port == 0, max port == 65535 -- if min port == 0, uses existing random port selection (range ignored)
add 'gathering_started' flag to avoid changing ports after gathering has started
validity checks: min port <= max port enforced, error thrown otherwise
include tests to ensure port range is being utilized (by @hhardy)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/119>
As advised by !1366#note_629558 , the nice transport should be
accessed through:
> transceiver->sender/receiver->transport/rtcp_transport->icetransport
All the objects on the path can be accessed through properties
except sender/receiver->transport. This patch addresses that.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1952>
On renegotiation, or when the user has specified a mid for
a transceiver, we need to avoid picking a duplicate mid for
a transceiver that doesn't yet have one.
Also assign the mid we created to the transceiver, that doesn't
fix a specific bug but seems to make sense to me.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1902>
