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.
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.
This change adapts pion/ice to use a new interface for most network
related operations. The interface was formerly a simple struct vnet.Net
which was originally intended to facilicate testing. By replacing it
with an interface we have greater flexibility and allow users to hook
into the networking stack by providing their own implementation of
the interface.
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.
Introduces AddEncoding method in RTP sender to add simulcast encodings.
Added UTs for AddEncoding.
Also modified the Simulcast send test to use the new API.
Problem:
--------
In the following negotiation sequence, the Simulcast track is lost.
1. Remote Offer with Simulcast tracks with rids
2. A new track added to Remote Offer with tracks using SSRCs
When the updated `offer` is received, the Simulcast transceiver's
receiver gets overwritten because the tracks from SDP is compared
against current transceivers. The current transceiver for the
Simulcast track already had SSRCs set as media has been received.
But, tracks read from the SDP only has `rid`. So, no current
transceiver matches and hence a new receiver is created which
clobeers the good Simulcast receiver.
Fix:
----
- Prioritize search by `rid`.
- Also found a case of a loop where the index was missing entries
in the loop. Fix it.
Testing:
--------
- The above case works
It isn't possible to send media if a MediaEngine has no codecs. This
catches a common misconfiguration issues that users find themselves in.
Resolves#1702
now proctected by lock:
- CreateOffer
- CreateAnswer
- AddTransceiverFromKind
- AddTransceiverFromTrack
newRTPTransceiver is no longer a PeerConnection method;
pc.addRTPTransceiver would fire onNegotiationNeeded;
pc.AddTrack, pc.RemoveTrack now hold lock for the entire function;
Fixes TestNegotiationNeededStressOneSided() by waiting til all
tracks added to pcA and the negotiation completed
Which were previously unable to:
1. have a sending track set to them, or
2. receive a track after renegotiation.
I'm not 100% sure if this covers all cases where a track is added and
removed and then added again. BUT IIRC there was a change that did not
allow transceiver reuse after a track was removed from it. Again, not
100% sure.
Fixes#1722.
