handleIncomingSSRC will call streamsForSSRC which
opens rtp/rtcp streams that if unhandled can be
leaked resources. Now we will proactively open
them before calling handleIncomingSSRC and close
then later. In the future it would be better to
do this inside handleIncomingSSRC to protect other
callers.
Added support for SRTP_NULL_HMAC_SHA1_80 protection profile (cipher).
It is disabled by default. You need to use SettingEngine and set list
of allowed SRTP protection profiles using its SetSRTPProtectionProfiles
function called with dtls.SRTP_NULL_HMAC_SHA1_80 as a parameter. You
need to do this for both pion peers. For non-pion ones you may need to
enable it somewhere too, as NULL cipher is usually disabled for security
reasons.
Add an option in the setting engine to log TLS key material when a
DTLS connection is established with a peer.
The option exists in pion/dtls but is not easily accessible
Read + Discard packets from the Simulcast repair stream. When a
Simulcast stream is enabled the remote will send packets via the repair
stream for probing. We can't ignore these packets anymore because it
will cause gaps in the feedback reports
Resolves#1957
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
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
This modification attempts to fix a deadlock happens when closing a
peer-connection.
The deadlock scenario is:
- routine-1: DTLSTransport.Stop is called during closing, which holds
the writer-lock of DTLSTransport, and it blocked by accepting from
session.closed channel when trying to close SRTPSession.
- routine-2: its stacks located in the routine launched in
srtp.session.start(...), this routine should close the session.closed
channel, however, it blocked when sending to
srtp.SessionSRTP.session.newStream
- routine-3: this routine should call strp.SessionSRTP.AcceptStream
to release routine-2. However, it blocked when calling
DTLSTransport.getSRTPSession(), it requires the reader-lock.
To resolve this issue, the instance of SessionSRTP is kept in
atomic.Value and avoid the requirement of reader-lock in
DTLSTransport.
Fixes#1430
Sometimes the replay protection of SRTP and SRTCP needs to be disabled.
This change adds disableSRTPReplayProtection and
DisableSRTCPReplayProtection helpers to SettingEngine.
