Map iteration order is not guaranteed by Go, so it's an error to iterate
over a map in places where maintaining the same ordering is important.
This change replaces the map of simulcastRid{} with an array of the same
type. The simulcastRid{} type is extended to hold the rid-id which
previously was used as the key in the map.
Accesses to the map are replaced with range loops to find the desired
rid-id for each case.
Fixes#2838
When running the reflect example against Firefox 99.0.1 I was receiving
errors around parsing the SDP from Pion.
The error was:
SIPCC Failed to parse SDP: SDP Parse Error on line 50: c= connection
line not specified for every media level, validation failed.
According to the RFC
[4566 5.7](https://datatracker.ietf.org/doc/html/rfc4566#section-5.7)
A session description MUST contain either at least one "c=" field in
each media description or a single "c=" field at the session level.
It MAY contain a single session-level "c=" field and additional "c="
field(s) per media description, in which case the per-media values
override the session-level settings for the respective media.
I don't see any errors in the Pion repos for this. Interestingly the
webrtc-rs project that is porting Pion to rust has
[an issue](https://github.com/webrtc-rs/webrtc/issues/144)
where they're encountering this same error.
rfc8839#section-5.1 specifies that a WebRTC Agent MUST
ignore any name/value pairs it doesn't understand. When
we parse a candidate and it fails because we don't understand
the type we now log and continue.
Resolvespion/webrtc#1949
This reverts commit 6c3620093d.
This commit would cause sender.ReadRTCP() to never return
even when pc associated with this sender was closed.
The aftermath is leaked goroutines that will never stop.
Add an accessor to make getting value easy. Also add
TestPeerConnection_SkipStoppedTransceiver. This commit also cleans
up RTPTransceiver creation. We used a helper function, when we should
have just used the provide constructor
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
