When a new SSRC is seen we start a Read loop for the packets. However if
we only see one packet this loop will just sit forever. If a user
doesn't send us enough packets to finish probing it will prevent any
subsequent streams from being probed.
Relates to #1345
* Return error to user when remote doesn't support codecs
* Assert that bindings are properly incremented/decremented
* Assert that a added track doesn't error even when disconnected
Relates to #1526
Dropping a packet at the beginning of every track is bad, since
it corrupts the first keyframe of each video track. This works
by adding a peek method to Track, and using it in NewTrack.
The peeked data is protected by the RWLock already associated
with the track. We check for its presence with the reader lock
taken, which avoids taking the writer lock (or doing an atomic read)
in the common case (no peeked data).
Fixes#1001
Instead of having logic in pion/webrtc and pion/sdp move all logic to
pion/ice. Users of pion/ice don't want to import these packages to use
basic pion/ice functionality.
Operations is now essentially a slice protected by a single lock. No
lock is held during execution, serialisation is guaranteed by ensuring
that there is at most one goroutine running at a time. A coincidental
benefit is that we now won't deadlock if an operation panics.
While this should be slightly faster, the main point of this change is
to reduce the amount of noise in the blocking profile.
From PR #1158 during negotiation every required transceiver is assigned
to a specific media section (using the media section mid value).
The same should be done when starting receivers. We should start the
receiver assigned to the media section of that track.
Only start senders that were negotiated.
Since `startTransports`/`startRenegotiation` start rtp senders in a
goroutine, an user could call AddTrack/Add*Transceiver/RemoveTrack
causing a not negotiated sender track ssrc to be started.
This tries to better match the JSEP spec and will fix at least two
issues:
* #1171
* #1178
* Move transceiver selection/creation in SetRemoteDescription and
CreateOffer
* In SetRemoteDescription also create new Transceivers of type recvonly
when no satisfying transceiver is available
* In CreateOffer generate unique mid in number format avoiding possible
collisions with remote provide mids and to also already handle a future
implementation of m= section rejection and reuse
* Now generateMatchedSDP will just find the transceivers with the
required mid since they are already selected previously.
More details in these extract from JSEP:
JSEP 5.10 (Applying a Remote Description) says:
```
For each m= section, the following steps MUST be performed
[...]
If the m= section is not associated with any RtpTransceiver
(possibly because it was dissociated in the previous step),
either find an RtpTransceiver or create one according to the
following steps:
```
JSEP 5.2 (Constructing an Offer) says:
```
[...]
An m= section is generated for each RtpTransceiver
that has been added to the PeerConnection, excluding any stopped
RtpTransceivers;
```
Note that we are currently directly associating a mid to a transceiver
in CreateOffer, instead the spec says to also keep a m= section index
mapping to a transceiver and set the transceiver mid only when applying
the local description. This is needed to support rollback of proposed
offer/answer but currently we don't have support and tests for rollback
situations.
In SetLocalDescription guard iceGatherer.Gather by checking state.
We don't put this check inside Gather because ORTC doesn't have the
function as re-entrant
Resolves#1144
Co-authored-by: jeremija
When offering always put application first. Before during re-negotation
we would break the order if media sections because we would always place
it last. Instead of remembering what order the application was place
just always place it first.
Resolves#1055
This causes users who use PopulateFromSDP to declare
they support transport-cc. Since they don't send receiver
reports. They will get a degraded experience unexpectedly.
Partially revert ce8de088e7.
Resolves#1026
Add a new public method, GetRegisteredRTPCodecs, under PeerConnection
to allow access to get the registered list of RTPCodec from the
underlying MediaEngine for developers who want to build libraries on
top of pion.
Resolves#966
Before we computed DataChannel IDs before signaling, this
is incorrect because IDs must take into account if we are
running an DTLS Client or Server.
This updates the DataChannel ID generation code to take this
into account before generating a streamId.
Resolves#908
This test was added to assert that rogue RTP/RTCP packets didn't cause
us to leak. The code that was actually causing the leak was removed,
so this isn't actually testing anything useful anymore
Resolves#823
TestSRTPDrainLeak asserts that we notify the user
of SRTP/SRTCP packets that can't be handled. Before
we tested by sending 5 packets, and looking for a log
message. If these 5 packets were lost the test would fail.
Now we send packets in a loop until they are seen.
Resolves#823
