#### Description
Currently, Pion returns an empty `sdpMid` and a 0 `sdpMLineIndex`. This
PR ensures Pion returns the corresponding `sdpMid` and `sdpMLineIndex`
for ICE candidates for clients that expects it. Fixes trickle issues.
#### Changes
1. `ICECandidates`: New fields `SDPMid` and `SDPMLineIndex`.
2. `ICEGatherer`: `SetMediaStreamIdentification` and return the correct
`SDPMid` and `SDPMLineIndex`.
3. `extractICEDetails`: Return a struct instead of multiple values.
4. `extractICEDetails` refactored the media description selection to a
different function.
5. Added new tests.
#### Reference issue
Fixes https://github.com/pion/webrtc/issues/2690
Fixes https://github.com/pion/webrtc/issues/1833
The way currently DTLS fingerprints and ICE credentials
are picked is causing interop issues as described in #2621
Peers which don't use Bundle can use different fingerprints
and credentials in each media section. Even though is
not (yet) supported by Pion, receiving an SDP offer from
such a peer is valid.
Additionally if Bundle is being used the group attribute
determines which media section is the master bundle section,
which establishes the transport. Currently Pion always
just uses the first credentials/fingerprint it can find
in the SDP, which results in not spec compliant behavior.
This PR attempts to fix the above issues and make
Pion more spec compliant and interoperable.
Fixes#2621
If the MediaEngine contains support for them a SSRC will be generated
appropriately
Co-authored-by: aggresss <aggresss@163.com>
Co-authored-by: Kevin Wang <kevmo314@gmail.com>
Resolves#1989Resolves#1675
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
