CurrentRemoteDescription and PendingRemoteDescription both access
members of the PeerConnection that should be protected by a lock.
Co-authored-by: Markus Tzoe <chou.marcus@gmail.com>
in CurrentLocalDescription() or PendingLocalDescription():
when gathering local candidates in populateLocalCandidates(),
agent would try submitting a task via run():
a.chanTask <- task
the chanTask is consumed by a bg routine using taskLoop():
for {
select {
case <-a.done:
return
case t := <-a.chanTask:
t.fn(a.context(), a)
close(t.done)
after()
}
}
while there're other routines using the agent, e.g. calling
`agent.updateConnectionState()`
a.afterRun(func(ctx context.Context) {
a.chanState <- newState
})
and the submitted task would be run by the `after()` func in
`taskLoop()`, where the `a.chanState` is handled by
`agent.startOnConnectionStateChangeRoutine()`
this `after()` task may block the bg routine when there's ongoing
event handler `agent.onConnectionStateChange()`, which would
eventually call PeerConnection's onICEConnectionStateChange():
pc.mu.Lock()
pc.iceConnectionState = cs
handler := pc.onICEConnectionStateChangeHandler
pc.mu.Unlock()
which would try to hold the PeerConnection lock, causing deadlock
Use wasm_exec.js in GOROOT to ensure that the wasm file be loaded,
there is no need to use a specific version of go to build wasm,
and delete vendor-wasm.
DataChannel.open would panic during which if PeerConnection is closed,
stopping underlying sctpTransport which sets association to nil;
And ensureSCTP() method doesn't guarantee sctpTransport's availability
out of it's own scope.
Use fine granularity rw-mutex to protect rtpTransceivers and for
exclusively accessing AddTrack and RemoveTrack
Fixes `shouldAddCandidates` typo in sdp.go
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.
Exact match if fmtp parameters are not inconsistent.
e.g. default OPUS fmtp of the browsers are:
Chrome: minptime=10;useinbandfec=1
Firefox: maxplaybackrate=48000;stereo=1;useinbandfec=1
They should be treated as matched.
Before we would set the PeerConnection to failed, but we would leave the
DTLSTransport. This means that a user could still interact with the
other transports.
Relates to #1708
The peerIdentity field can be null, in which case the peer identity
is not checked. We used to send the empty string in that case, which
happens to work with common browsers but is probably incorrect.
The play-from-disk examples sees the average bitrate using
Chromium 90.0.4412.3 when enabled on loopback for a 3 minute
session.
Before: 744.443
After: 3927.669
Introduced with pion/interceptor@v0.0.10
When a local peer connection has a single transceiver with a sendrecv
direction, and the remote has a transceiver with a recvonly direction,
the local peer connection must change the transceiver direction to
sendonly.
When a local peer connection has a single transceiver with a recvonly
direction, and the remote has a transceiver with a recvonly direction,
the local peer connection must create another transceiver with a
sendonly direction.
A unit test is added to cover all possible cases.
