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.
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
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.
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.
This allows users of detached datachannels to garbage collect
resources associated with the datachannel and the sctp stream.
There is no functional change here.
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.
Everytime we receieve a new SSRC we probe it and try to determine the
proper way to handle it. In most cases a Track explicitly declares a
SSRC and a OnTrack is fired. In two cases we don't know the SSRC
ahead of time
* Undeclared SSRC in a single media section (pion/webrtc#880)
* Simulcast
The Undeclared SSRC processing code would run before Simulcast.
If a Simulcast Offer/Answer only contained one Media Section we
would never fire the OnTrack. We would assume it was a failed
Undeclared SSRC processing. This commit fixes the behavior.
When peerconnection create a transceiver by remote's recvonly
offer, the transceiver will have nil sender but can't be reused
since its currentDirection is set to sendonly. This pr change
the currentDirection to inactive so it can be reused by AddTrack.
When PeerConnection closed, need call unhandled stream's
close method to release buffer created by BufferFactory,
otherwise might cause resource leak if user
provide BufferFactory need close to release the resource.
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
