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
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.
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.
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.
Do the set up of RTP receivers synchronously so that they
are ready to receive media as soon as signalling to remote
side is sent. Once signalling to remote side is sent, the
remote can send media at any time and receiver has to be ready.
Like the bug mentions, a negotiation quickly followed by
a renegotiation left the RTP receivers of the tracks in the
second offer not set up. If the tracks in the renegotiation
happen to be simulcast tracks, they are missed as browsers
send RID only in the first few packets.
The problem can be reproduced by introducing a 1 second
delay in Downstream direction in Network Link Conditioner
and using a modified version of LiveKit JS SDK sample app to
force a double negotiation spaced closely.
With this change, onTrack fires, but the unhandled warning
from RTCP for the highest layer still happens. But, the
track fires almost immediately following that warning
(less than 5 ms later). So, all the simulcast layers
are available.
Resolves#2054
Read + Discard packets from the Simulcast repair stream. When a
Simulcast stream is enabled the remote will send packets via the repair
stream for probing. We can't ignore these packets anymore because it
will cause gaps in the feedback reports
Resolves#1957
If we have a media section with no SSRC we would fire an OnTrack. This
code now properly ignores a MediaSection that has a rid attribute.
Resolves#1808
This gives an option to raise the receive MTU as SettingEngine option.
If SettingEngine has not been set the MTU, then default value is used
instead, 1460
Resolves#1925
- Refine RTPReceiver.SetReadDeadline behavior
Instead of iterating over r.tracks, just calling r.tracks[0]
directly. This behavior follows RTPReceiver.Read.
- Add RTPReceiver.SetReadDeadlineSimulcast
Its fingerprint follows RTPReceiver.ReadSimulcast.
- Refine RTPReceiver.setRTPReadDeadline
It will only timeout the RTP stream for the track makes the call.
Previously, Reading RTP or RTCP packets from a peer
would block until a packet was received, or the
connection was terminated. This change allows you to
set a deadline, after which the read function will
return a timeout error and you can get on with other
things.
Resolves#1553
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
RTPTranseiver closees its streams on Stop if any have been received.
The receive trigger is closed as soon as the Receive function is called.
This is too early since the streams are added only directly after and
also there is the possibility that all or only one of the following
stream opens fail.
This change ensures that the receive channel is closed after all streams
have potentially been added. At the same time a check is added to ensure
that only streams which are actully opened are closed.
