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
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.
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.
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
Fix#2830. The TrackRemote.Read could block in
readRTP if the buffer is empty then rtx packets
arrival before next media rtp packet will be
readed after the next media rtp packet and cause
out-of-order fb and mess up remote peer's
bandwidth estimation.
handleIncomingSSRC will call streamsForSSRC which
opens rtp/rtcp streams that if unhandled can be
leaked resources. Now we will proactively open
them before calling handleIncomingSSRC and close
then later. In the future it would be better to
do this inside handleIncomingSSRC to protect other
callers.
Added support for SRTP_NULL_HMAC_SHA1_80 protection profile (cipher).
It is disabled by default. You need to use SettingEngine and set list
of allowed SRTP protection profiles using its SetSRTPProtectionProfiles
function called with dtls.SRTP_NULL_HMAC_SHA1_80 as a parameter. You
need to do this for both pion peers. For non-pion ones you may need to
enable it somewhere too, as NULL cipher is usually disabled for security
reasons.
libwebrtc has started sending media probes on an unannounced SSRC(0).
Currently Pion will ignore this as the SSRC hasn't been declared
explicitly and no RID/MID RTP Headers.
This adds a special case to accept SSRC 0 and Read the RTP packets. This
allows the TWCC reports to properly be generated.
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.
Currently, AV1 or VP9 formats are matched regardless of the profile
parameter. This was not noticeable until browsers started advertising
multiple VP9 formats at the same time, each with a different profile
ID, in order to allow the counterpart to send different streams on the
basis of supported profiles.
This causes two issues: first, the library includes in the SDP all
formats passed by the browser, regardless of the fact that the profile
ID is registered in the API or not. Then, the library is unable to
choose the correct format for streaming, causing an intermittent
failure.
This patch fixes the matching algorithm and also covers the case in
which the profile ID is missing, by using values dictated by
specifications.
Tests were refactored since previous ones covered the same lines
multiple times.
In the case where a remote track is sending PCMU with payload type 0
checkAndUpdateTrack will fail to update the track codec and params
(because t.PayloadType() is already 0). Add an extra check to handle
this case.
Fix#2751, updates remote track's rtx ssrc for
simulcast track doesn't contain rtx ssrc in sdp
since readRTX relies on rtx ssrc to determine if
it has a rtx stream.
The SCTP implementation used in v3.2.28 fails to establish a connection
with other WebRTC implementations. The implementation of ZeroChecksum
assumes incorrectly that the feature is bi-directional
SCTP ZeroChecksum is actually a uni-directional feature which causes the
Assocations to be unable to communicate.
