If we have a media section with no SSRC we would fire an OnTrack. This
code now properly ignores a MediaSection that has a rid attribute.
Resolves#1808
Instead of having logic in pion/webrtc and pion/sdp move all logic to
pion/ice. Users of pion/ice don't want to import these packages to use
basic pion/ice functionality.
Extmaps are configured via the SettingEngine. This allows a user
to set arbitrary values, and when answering ids and entries are
properly excluded.
Co-authored-by: Gabor Pongracz <gabor.pongracz@proemergotech.com>
This commit adds an option to put DTLS Fingerprint specification
at the media description level rather then the session description
level. This enhances compatibility with some 3rd party webrtc
implementations (notably Kurento).
From PR #1158 during negotiation every required transceiver is assigned
to a specific media section (using the media section mid value).
The same should be done when starting receivers. We should start the
receiver assigned to the media section of that track.
This modification will only keep incoming tracks from media sections
with `a=sendrecv` or `a=sendonly` attributes. This modification is not
necessary for pion-to-pion peer connections, but for browser-to-pion
connections using Unified Plan.
Background:
When a `RTCPeerConnection#removeTrack()` is called in the browser and
the connection is renegotiated, the browser (tested in Firefox 75.0)
will change the media section attribute to `a=recvonly` from
`a=sendrecv`, or `a=inactive` from `a=sendonly`, but will keep the same
`a=ssrc:<ssrc>` associated with the same media (mid) section.
Previously, when a remote track obtained with Pion's `OnTrack()` handler
was being read from, and this remote track was later removed in the
browser, the track's `Read()` method would never return `io.EOF` (unless
the peer connection was closed).
With this commit, the `trackDetailsFromSDP` function will only include
remote track details whose media section has `a=sendonly` or
`a=sendrecv` attributes, and previously existing logic will ensure that
a receiver for that specific ssrc is stopped, so that
`webrtc.Track#Read()` method returns `io.EOF`.
If the remote description contains rtx information via a `ssrc-group`,
the extra `ssrc` entries must be ignored to ensure thats no receiver
is added for them.
This can solve issues like `Incoming unhandled RTP ssrc(1858531374)` if
those are caused by a wrong receiver getting started for the rtx ssrc
but not for the track ssrc, based on the ssrc/transceiver oder in the
remote description.
Until rtx is properly supported, this change fixes the imediate issue
that some remote streams are randomly not received because of a remotes
rtx information.
Fixes: #1081
Related: #1083
