RTCPeerConnections have several states but, for simplicity, for now the
events posted reflect only if the connection is fully established or
not (which includes both a broken connection or an established
connection that is unstable or being updated), which is enough for a
basic information about the connection state in the UI.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
After the migration from WebRTC from plan b to unified plan in commit 86f20dc
the media constraints are ignored for creating an answer on a peer
connection:
> Offer to Receive Options/Constraints
>
> These constraints are passed to PeerConnection’s methods for creating SDP to
> add placeholder media sections in case a sending track would not have already
> created one.
>
> With Unified Plan semantics, these are still supported for creating offers
> using a backwards compatibility shim (basically creating an RtpTransceiver if
> one doesn’t exist). It is recommended to switch to the RtpTransceiver API
> (example below). _They are no longer supported when creating answers._
>
> [1]
Because of that now all transceivers of type VIDEO will be stopped if it
is only an audio call. After stopping the transceivers the status for the
video tracks will be automatically set to ENDED.
In the 'ParticipantsAdapter' it will be checked if the video tracks are
ENDED. In that case the user avatar will be shown like before.
Resolves: #1852
See: #1773, commit 86f20dc, [1]
[1] https://docs.google.com/document/d/1PPHWV6108znP1tk_rkCnyagH9FK205hHeE9k5mhUzOg/edit#heading=h.9dcmkavg608r
Signed-off-by: Tim Krüger <t@timkrueger.me>
