Update MediaEngine codec creation to take into account remote
and local rtcp-fb. Before we would incorrectly always take
the remote rtcp-fb and ignore local.
Resolves#2943Resolves#2944Resolves#1968
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
Firefox would send updated header extension
in renegotiation, e.g. publish a track without
simucalst then renegotiate second track with
simucalst, the two media secontions will have
different rtp header extensions in offer. Need
to match remote header extentions for each
media sections to avoid second track publish
failed.
Always handle header extensions from packet read
from interceptor, let interceptor has consistent
chance to process headers
Fix rtx is not negotiated when there is multiple
codecs has same mime but different profile (H264)
Fix rtx stream info missed when SSRC group attr
shows after base track's ssrc attr.
This change adapts pion/ice to use a new interface for most network
related operations. The interface was formerly a simple struct vnet.Net
which was originally intended to facilicate testing. By replacing it
with an interface we have greater flexibility and allow users to hook
into the networking stack by providing their own implementation of
the interface.
This test previously assumed deterministic (i.e. ordered)
behaviour for getRTPParametersByKind which is not necessary, and
is no longer true following PR #2236 due to use of range. The
result was that occasionally this test would fail incorrectly
(thanks, golang-ci). This PR fixes the test.
This PR addresses an issue whereby under a specific (but not unusual)
circumstance. Pion fails in two different ways to generate the correct
SDP extmap IDs for a track. Some browsers are more picky about this
than others, but Firefox is known to be picky and this issue may be
responsible for some reported incompatibilities.
Sequence to trigger the issue:
* Pion side registers audio & video codecs and audio & video header
extensions.
* Pion side gets an audio-only offer from the remote, and responds
with an answer.
* At some later point in time, Pion side wants to add a video track
and prepares a new offer.
* Extmap IDs in the new offer SDP are usually incorrect
conflicting/misassigned
Co-authored-by: Hugo Tunius <hugo@lookback.io>
Relates to: webrtc-rs/webrtc#154
This avoids a bug where negotiating Opus with PT 96 in an audio-only
session results in the VP8 codec being picked for a track (because
96 is the built-in type for VP8).
It isn't possible to send media if a MediaEngine has no codecs. This
catches a common misconfiguration issues that users find themselves in.
Resolves#1702
codec has apt fmtp can't negotiation because it's
apt payloadtype can't be found in negotiation codecs.
rtx codec must be partial match if apt codec is partial.
Was reverted in eeb67e1Fixes#1785
RegisterHeaderExtension now allows users to enable headers depending on
the type of transceiver that was created.
Also expose GetParameters on RTPSender and RTPReceiver
Co-authored-by: OrlandoCo <luisorlando.co@gmail.com>
Resolves#1554
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.
This causes users who use PopulateFromSDP to declare
they support transport-cc. Since they don't send receiver
reports. They will get a degraded experience unexpectedly.
Partially revert ce8de088e7.
Resolves#1026
Fixes#515
This includes a few small and closely related changes:
1. All occurrences of the build tag `+build js` have been changed to the
more precise `+build js,wasm`. This will exclude the files from being
included by third-party compilers like GopherJS, with which they are
incompatible.
2. Some files which are incompatible with JavaScript/Wasm now have the
correct build tag (`+build -js`) so they will be excluded from Wasm
builds.
3. Some configuration options which are incompatible with
JavaScript/Wasm (or at least the current bindings) will now no longer
appear in Wasm builds. This meant creating new files with new struct
definitions and the appropriate build tags.
