Firefox camera tracks do not fire onTrack when screen share
and camera is negotiated in the same offer.

There were two issues

1. When updateRemoteDescription runs, only the first
media description of a specific kind was considered.
So, when screen was before camera, screen did not
$ave RID in extmap. It is in the camera section as
video is using simulcast. All the extra ones in the
camera section were ignored.

Parse all descriptions and collect extensions to fix it.

2. This one sounds like a Firefox issue. When sending
answer back, if the screen share section has the
RID, Firefox seems to get stuck. It does not send
screen or camera media and after 15 seconds, the
peer connection fails.

To address that, store extensions from SDP in
transceiver and while constructing answer SDP,
cross check against transceiver's negotiated
extensions before adding it to the answer SDP.

The reason I think this is a Firefox issue is
because how it behaves before this change when
camera is negotiated first and screen later in
a separate offer. When screen is negotiated
later, answer does send back RID and it works.
Looks like Firefox has an issue seeing RID
before it expects it.

Testing
--------
Used LiveKit JS SDK sample to negotiate screen and
camera together.

This was not an issue with Chrome as I could not
get Chrome to negotiate screen and camera in the
same offer with screen ahead of camera.

…share_and_camera

If the SRTP Stream hasn't been opened yet we would attempt to process
(and fail) RTP traffic. This change causes us to not even attempt to
read.

No behavior change from this, but will cause less useless logging.

`AcceptStream` will then be fired again for this SSRC. We depend on the
behavior of AcceptStream only returning once for each SSRC.

Generated by renovateBot

Assert that Simulcast probe thread doesn't close the Tracks that have
been emitted to the user.

When creating answer, check ICE role while determining DTLS role.
ORTC thread on how roles are set
w3c/ortc#167 (comment)

When remote is ice-lite and there is no answering role set,
the answer uses the default which is DTLS client. So 'setup'
is set as 'active' and answer sent.

But, when DTLS transport is started, it checks the ICE role
and sets itself as DTLS server (because remote is lite
and hence local agent becomes controlling ICE agent).

So, both sides end up being DTLS server and nobody sends
client hello.

DTLS should be able to be negotiated over an already established
ICETransport

Resolves #2113

DTLS v2.1.2 fixes a bug with long delay connections.
https://github.com/pion/dtls/releases/tag/v2.1.2

copySessionDescription adds a button to all examples that copies the
local Session Description. This makes it easier for users to copy the
values.

Resolves #2092

Been running these locally only.

Generated by renovateBot

Add SetDTLSRetranmissionInterval setting to SettingEngine.

Add test for SetDTLSRetransmissionInterval

Update lint scripts and CI configs.

Only available in the browser, not in wrtc yet.

Resolves #2099

…share_and_camera