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
This change adds constants for H265 and AV1. Neither are fully
supported in pion, however these constants are still useful and we will
likely send a change to add H265 and AV1 packetizer/depacketizers in
the future.
This avoids a bug where negotiating Opus with PT 96 in an audio-only
session results in the VP8 codec being picked for a track (because
96 is the built-in type for VP8).
If PeerConnection removes track while RTPSender is
created and being negotiated, RTPSender.Send would
access nil pointer. Check If track is nil.
Relates to #2065
in some case like session migration from one sfu node
to another, we need manual set mid of transceiver instead of
auto generate, to make mid consistent between to sfu node.
This is not needed. We don't perform any operations on inbound RTCP
packets. Receiver Reports and TWCC are generated by Reading RTP packets.
This reverts commit 080d7b8427.
If SetRemoteDescription is called with offer SDP which
has a=invalid, PeerConnection sets its transceiver direction
as recvonly. Fix direction recvonly to invalid.
Resolves#2050
data-channels-close demonstrates that you are able to close a
DataChannel. Closing a DataChannel isn't exercising any unique
behaviors. I don't believe it will help users discover anything new or
prevent them from making mistakes.
data-channels-(detach)-create demonstrates creating a DataChannel in Go.
We have a 1:1 mapping with the browser so I think this is expected. We
also have other examples demonstrate this behavior.
If a RTPSender doesn't have a track currently set and GetParameters is
called we would call a method on a nil pointer. Now instead of checking
the Track kind we store the kind in the RTPSender.
Resolves#2065
rfc8839#section-5.1 specifies that a WebRTC Agent MUST
ignore any name/value pairs it doesn't understand. When
we parse a candidate and it fails because we don't understand
the type we now log and continue.
Resolvespion/webrtc#1949
rfc8839#section-5.1 specifies that a WebRTC Agent MUST
ignore any name/value pairs it doesn't understand. When
we parse a candidate and it fails because we don't understand
the type we now log and continue.
Resolvespion/webrtc#1949
If a transceiver is created by remote sdp, then set
prefer codec same as offer peer.
For pion's codec match, it will use exact match
first, and then partial match. If patial match
only, the partial match codecs will become
negotiated codes. So it will be set prefer codec
when only exist partial match. And has same payload.
Add test cast for this.
refer to https://www.w3.org/TR/webrtc/#bib-rfc8829
Two separate potential deadlocks
1. typically the locking order is SRTP first, then DataChannel.
However, when data channel is opened, it's locking srtp when
generating an ID.
It also would return without unlocking when an error is encountered
2. recursive RLock could be potentially problematic. MediaEngine
contained a section doing so.
A race existed with Negotiated DataChannels before this. Before
the remote could sends us a DataChannel message before the
datachannel was negotiated locally. We would then discard the
message and print an error.
This PR moves the processing of remote datachannel messages after
we have registered all local ones. It also informs
datachannel.Accept of existing datachannels in order to prevent
any initialization logic from proceeding incorrectly.
Fix regression from 0180ee. Before Datachannels would always fire
OnOpen. Now they only fire when DCEP ACK is received. This caused
OnOpen to not be fired for negotiated channels. This re-enables
the previous behavior of firing OnOpen for negotiated channels.
Add 'copy browser Session Description to clipboard'. This makes it
easier to copy the Session Description. Before users would accidentally
not copy the entire value
