This allows users of detached datachannels to garbage collect
resources associated with the datachannel and the sctp stream.
There is no functional change here.
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.
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.
Using an improvment of pion/datachannel, the channel opener can now
set an event to be called when the DATA_CHANNEL_ACK message is recieved
Resolves#1063
Relates to pion/datachannel#81
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.
The change in #1520 unnecessarily waits for a client-provided callback
to complete before release resources that are no longer necessary.
Won't have any impact in microbenchmarks that have no-op callbacks.
Release as early as possible.
OnOpen handler is sometimes called with a huge delay in
TestDataChannel_Open and causes handler_should_be_called_once
failure.
This commit minimizes mutex lock scope around handler registration
and removes redundant mutex.
Also, add sleep before closing PeerConnections in
TestDataChannel_Open to ensure all messages are processed.
DataChannel readyState should be set to Closed on PeerConnection
shutdown. If not properly set it would attempt to interact with
state that doesn't exist after the PeerConnection has been Closed.
Setting the readyState is also clearly defined in the W3C webrtc-pc
Resolves#915
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
In lots of our event handlers we return the event status.
This is so we can know if the callee has finished. In lots
of cases we don't care so get rid of them to simplify the code.
The current dataChannelBufferSize is less than the limit used in
WriteSCTP (called by Send), which means that peers using this
implementations of WebRTC can send messages that will be thrown out by
Read because of an io.ErrShortBuffer error.
In the case that the message is too long, a more appropriate response
would be to close the channel and issue an error rather than log a
warning and continue reading data.
