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
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.
Before a SessionDescription was assumed to be Plan-B if it contained a
MediaName of `audio` or `video`. This PR Changes that behavior.
If SDPSemantics is UnifiedPlan the SessionDescription must contain a
MediaDescription with two SSRCes to be considered a Plan-B. Before if
the MediaDescription had name of `audio` or `video` it was assumed to be
Plan-B.
If SDPSemantics is PlanB or UnifiedPlanWithFallback it maintains the
existing behavior.
Resolves#2193
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
Before users could pass a SessionDescription with a 0 type. This would
be discarded silently. Now we return an error that matches browser
behavior.
Resolves#1297
Fix RemoteDescription parsing so that it parses all sections when
looking for a fingerprint, before it would fail if the first section
did not contain one
Previously the PeerConnection would create invalid SDPs
when answering an offer that contained codecs it didn't
know about. Now it rejects them by setting the media format
to 0.
Related to #449
Add OnICECandidate and OnICEGatheringStateChange methods to
PeerConnection. The main goal of this change is to improve API
compatibility with the JavaScript/Wasm bindings. It does not actually
add trickle ICE support or change the ICE candidate gathering process,
which is still synchronous in the Go implementation. Rather, it fires
the appropriate events similar to they way they would be fired in a true
trickle ICE process.
Remove unused OnNegotiationNeeded event handler. This handler is not
required for most applications and would be difficult to implement in
Go. This commit removes the handler from the JavaScript/Wasm bindings,
which leads to a more similar API for Go and JavaScript/Wasm.
Add OnICEGatheringStateChange to the JavaScript/Wasm bindings. Also
changes the Go implementation so that the function signatures match.
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.
The tests are run in a Node.js environment, and this does not include
any browser tests. This requires the wrtc package from npm as well as a
shim which adds portions of the WebRTC API to the global scope.
Some tests introduced here can be combined when differences between the
Go API and the WASM bindings are addressed and as missing features are
added to the WASM bindings.
We can and should add more tests in the future to improve test coverage.
This should be considered the minimum number of tests reuqired to ensure
basic functionality is working.
