It is entirely possible that the in progress may still provide some state
updates until the ICE object is destroyed, these state updates should
not really be done when webrtcbin is in the process of destroying itself
and access freed data.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9216>
This helps debug cases when the remote is offerer and m-line does not match with already existing transceivers.
In this case, it will create new ones with sendrecv direction without any warning.
Similar with code from _create_answer_task
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8735>
Fixes an issue where the webrtcbin would hangup when finalizing due
to the sctpenc hanging up when finalizing. This occurred when the
webrtcbin chose to use a sctp association ID already in use.
The sctpenc would fail to reach the paused state, but startup a task
anyways that was never stopped.
This commit modifies the behavior to not choose sctp association IDs
randomly, and instead only choose one that is free. It also prevents the
sctpenc from starting up that task if it fails to reach the paused state.
Fixes: #4188
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8607>
Before this patch, there could be duplicate payload types in offers that
have, within a media section, multiple codecs and RTX enabled:
```
m=video 9 UDP/TLS/RTP/SAVPF 96 97 97 <-- HAS DUPLICATES
a=sendrecv
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 transport-cc
a=rtpmap:97 H264/90000
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 transport-cc
a=rtpmap:97 rtx/90000 <--------- PT IS DUPLICATE
a=fmtp:97 apt=96
```
Fix this by populating the media_mapping array with all media formats
rather than only the first one. The added test case reproduces the issue,
which fails without this patch.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8259>
Adds a new signal to webrtcbin, to allow for placement
of an object after rtp, before sendbin. This is usable for
objects such as congestion control elements, that don't want
to be burdened by the synchronization requirements of rtpsession.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7940>
Parsing the whole caps as SDP media only to retrieve the fmtp field afterwards
seems a bit superfluous. By looking up the a-fmtp attribute directly the number
of allocations in this function gets down a bit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8125>
When a datachannel within a session is removed after proper close,
reference to the error_ignore_bin elements of the datachannel
appsrc/appsink were left in webrtcbin.
This caused the bin-objects to be left and not freed until the whole
webrtc session was terminated. Among other things that includes a thread
from the appsrc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7675>
Check and generate remote reception statistics from the info stored on
internal sources, as they are stored there when running against newer rtpbin
since MR !7424
This fixes cases where statistics are incomplete when
peers send RR reports from a single remote ssrc, which GStreamer does
when bundling is enabled and other RTP stacks may too.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7425>
If the pending remote description has an invalid BUNDLE group _parse_bundle()
triggers early return from _create_answer_task(), before ret has been
initialized, so it needs to be checked before attempting to call
gst_sdp_message_copy().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7423>
webrtcsrc first creates recvonly transceivers with codec-preferences
and expects that after applying a remote description, the
previously created transceivers are used rather than having new
transceivers created.
When pairing webrtcsink + webrtcsrc, the offer sdp from webrtcsink has a media
section with sendonly direction. In !7156, which was implemented following
RFC9429 Section 5.10, we only reuse a unassociated transceiver when applying a
remote description if the media is sendrecv or recvonly, and that caused creation
of new transceivers when applying a remote offer in webrtcsrc, thus losing
information from codec preferences like the RTP extension headers in the
previously created transceivers.
Since the change in !7156 broke existing code from webrtcsrc, relax the condition
for reusing unassociated transceivers and add a test to document this behavior which
wasn't covered by any tests before.
Fixes#3753.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7417>
When multiple streams are bundled on the same transport,
the statistics would end up incorrectly generated,
as each pad would regenerate stats for every ssrc on the
transport, overwriting previous iterations and assigning
bogus media kind and other values to the wrong ssrc.
Fix by making sure each pad only loops and generates
statistics for the one ssrc that pad is receiving / sending.
Add a unit test that the codec kind field in RTP statistics
are now generated correctly.
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2555
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7338>
When checking for renegotiation against a local offer,
reverse the remote direction in the corresponding answer
to fix falsely not triggering on-negotiation needed when
switching (for example) from local sendrecv -> recvonly
against a peer that answered 'recvonly'.
In the other direction, when the local was the answerer,
renegotiation might trigger when it didn't need to -
whenever the local transceiver direction differs from
the intersected direction we chose. Instead what we want
is to check if the intersected direction we would now
choose differs from what was previously chosen.
This makes the behaviour in both cases match the
behaviour described in
https://www.w3.org/TR/webrtc/#dfn-check-if-negotiation-is-needed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7303>
Fixes for basic rollback (from have-local-offer or have-remote-offer to
stable). Allow having no SDP attached to the webrtc session description
in that case, and avoid all the transceiver and ICE update logic
normally applied when entering the stable signalling state
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7304>
Fix an inverted condition when checking if sink pad caps match
the codec-preference of an unassociated transceiver, and
fix a condition check for transceiver media kind to
avoid matching sinkpad requests where caps aren't provided
against unassociated transceivers where the caps might
not match later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7237>
With MR 7156, transceivers and transports are created earlier,
but for sendrecv media we could get `not-linked` errors due to
transportreceivebin not being connected to rtpbin yet when incoming
data arrives.
This condition wasn't being tested in elements_webrtcbin, but could be
reproduced in the webrtcbidirectional example. This commit now also
adds a test for this, so that this doesn't regress anymore.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7294>
According to https://w3c.github.io/webrtc-pc/#set-the-session-description
(steps in 4.6.10.), we should be creating and associating transceivers when
setting session descriptions.
Before this commit, webrtcbin deviated from the spec:
1. Transceivers from sink pads where created when the sink pad was
requested, but not associated after setting local description, only
when signaling is STABLE.
2. Transceivers from remote offers were not created after applying the
the remote description, only when the answer is created, and were then
only associated once signaling is STABLE.
This commit makes webrtcbin follow the spec more closely with regards to
timing of transceivers creation and association.
A unit test is added, checking that the transceivers are created and
associated after every session description is set.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7156>
Don't add an extra ref if non-floating as that ref will never be
unreffed.
gst_bin_add() is transfer floating (alias to transfer none).
Fixes a leak when a non-floating ref was provided as a return value in
the request-aux-sender signal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6807>
The transport stream only returned the CAPS for the first matching PT entry
from the `ptmap`. Other SSRC with the same PT where not included. For a stream
which bundled multiple audio streams for instance, only the first SSRC was
knowed to the SSRC demux and downstream elements.
This commit adds all the `ssrc-` attributes from the matching PT entries.
The RTP jitter buffer can now find the CNAME corresponding its SSRC even if it
was not the first to be registered for a particular PT.
The RTP PT demux removes `ssrc-*` attributes cooresponding to other SSRCs
before pushing SSRC specific CAPS to downstream elements.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6119>
In rtpbin we already systematically check for all property names
except latency, correct that.
In webrtcbin we need to check before trying to use the do-retransmission
property.
This is useful for the case where an element like identity gets passed
to rtpbin's request-jitterbuffer property, when the application wants
to use webrtcbin in an SFU situation, with no reordering and no added
latency
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6112>
Remove optional sprop-stereo and sprop-maxcapture fields from Opus
remote offer caps before intersecting with local codec preferences.
According to https://datatracker.ietf.org/doc/html/rfc7587#section-7.1
those fields are sender-only informative, and don't affect
interoperability.
Fixes cases where the webrtc media will end up receive-only if the
local side wants to send stereo but the remote is sending mono, or
vice versa.
There may be other fields in other codecs, so the implementation
anticipates needing to add further fields and codecs in the future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5993>
The code seems to validate that the media-level fingerprint matches
the fingerprint of the previous media or of the whole session. There
is no such requirement in any RFC I found. The session-session one
is just meant to act as a fallback when there is no media-level
fingerprint.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1118>
