Close peerconnection on DTLS.CloseNotify
could break ice restart with dtls restart,
when the dtls finger-print changed, the
browser could teardown the old dtlstransport
and establish new one then pion could close
the peerconnection and restart failed. So
browser don't do this and spec also don't
say peerconnection should close when dtls
is closed.
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
Raise the default ReceiveMTU to 1500, as same
as the default MTU setting of WebRTC. This is because
some senders, i.e. FFmpeg, may packetize RTP with 1460
payload + 12 RTP header + etc.
Fixes#2927
The performance of the SampleBuilder is significantly worse when using
the SampleBuilder. It would be good to evaluate improving the
performance of the JitterBuffer. However for the time being we are just
going to revert.
Resolve#2778
In use cases like SFU, it is useful to get just the selected candidate
pair stats to have access to current RTT on the peer connection. The
standard has a way to do `GetSelectedCandidatePair` on `ICETransport`,
but does not have a way to get stats of that pair.
Although not in standard, adding a method to `ICETransport` to get
selected candidate pair along similar lines of above method.
Pion extracts them from ssrc-group line so this didn't failed
Pion<->Pion. Chrome/FireFox uses the dedicated a=ssrc lines and our
Offer/Answer would break negotation
Fixes#2922
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
Should not reuse transceiver (remove & add track)
in one round negotiation, it cause the transceiver
changes ssrc/id without transit to inactive and the
remote peer connection can't fire track close and
OnTrack event.
