It's an anti-pattern when using sync.RWMutex in golang.
After acquiring two reader privilege of a rwlock, it will deadlock if
another routine tries to acquire a writer lock.
In pion/webrtc, this calling sequence might happen when calling
GetTransceivers during track events.
Resolves#1425
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.
Before users could pass a SessionDescription with a 0 type. This would
be discarded silently. Now we return an error that matches browser
behavior.
Resolves#1297
Extmaps are configured via the SettingEngine. This allows a user
to set arbitrary values, and when answering ids and entries are
properly excluded.
Co-authored-by: Gabor Pongracz <gabor.pongracz@proemergotech.com>
This commit adds an option to put DTLS Fingerprint specification
at the media description level rather then the session description
level. This enhances compatibility with some 3rd party webrtc
implementations (notably Kurento).
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
According to @at-wat's suggestions. In my previous commit, there was no
guarantee that the initial Track().id and Track().label would be set
before the second answer with a `a=msid` section was received.
During re-negotiation we didn't properly filter SSRCes that we had
already handled. This makes sure to loop the existing transceivers
and asserts we don't try to handle the same SSRC again.
Resolves#1122
Edge prechromium does not like app data section before video/audio.
It generates the following error:
0: Unable to get property 'state' of undefined or null reference
rtcpeerconnection.js (1016,1)
Each negotation must be finished before processing the next one.
Before we would process multiple calls at once, and since they are
performed async we would have undefined behavior.
Resolves#1074
