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
