* Add sort by option to node selector
Allow the final decision of a selected node to be based on different
sorting options rather than just random.
Add a `sysload`, `cpuload`, `rooms`, `clients`, `tracks`, and
`bytespersec` sorting options to select the appropriate room when
multiple are suitable for the chosen selector.
Add tests for sysload sort_by option
Closes: #598
* NodeSelector: rename "random" selector to "any"
Since the selector introduces limits but the final selection is now
based on the sort by value, the random selector name does not make
sense. Rename this selector to "any" to accurately reflect that it will
select any available no with no additional selection limits.
Allow the old setting "random" to point to the new selector name, but
print a deprecation warning message.
Sometimes peerconnection jumps to disconnected periodically even
when the underlying connection is ok. In these cases we are
triggering unnecessary connection restarts.
Given this, we'll leave the responsibility of early-detecting
disconnections to clients, where they have more control/knowledge
of networking conditions.
* use negotiated data channel in migration case
* create subscriber data track after migration
* fix participant state update
* add participant leave log
* update protocol
Found another reason for potential stalling on layer switch up.
When switching up, it is possible that the key frame of the packet
at higher layer arrives very close to a packet in the currently
forwarded layer.
An inversion happens when higher layer packet arrives earlier
(as timestamped at receicver), but gets scheduled for forwarding
later (as seen by forwarder).
Because of the order of processing goroutines,
it is possible to have negative diff when trying to adjust
RTP timestamps for layer switch. A negative diff results in
large jump in RTP timestamp. Client stalls, sends PLI three seconds
later (3 seconds is a Chrome thing, not sure about others), waits
for another key frame and starts again. In the mean time, the
video is frozen.
* Handle an edge in layer lock.
A very edge case
- Available layer: [0, 1, 2], but bitrate is not yet available.
We set it to layer 2 awaiting measurement.
- Measurement for layers 0 and 1 come through.
- Still no key frame for layer 2.
- Finalize layers runs and sees that bitrate is available for 0 and 1.
It finalizes layer 1.
- Layer 1 key frame comes (because we asked key frame of layer 2,
publisher sends key frame for all layers). Locks to layer 1.
- No more events happen to switch to layer 2.
Changes
-------
- Move bit rate measurement to StreamTrackerManager. Allows re-use
in relay.
- Make bit rate availability (from zero -> non-zero) an event
and let it flow through the stream allocation flow so that we
always have an event when bit rate measurement becomes available.
This gets rid of finalization which I was unhappy with it anyway as
it was polling every second.
- Removing REMB stuff from buffer. We do not use it.
It is incorrect anyway. REMB should be ay peer connection level.
* Fix test
* fix test
* Simplify allocate
* Simplify/clean up
* feat: unpublish tracks after publish permissions are revoked.
Uses protocol 7 to indicate client support, otherwise it attempts to
mute the tracks.
Also sends back permissions objects of all participants, and cleaned up
our handling of various permissions attributes.
* fix static check
