* Set layer state to `stopped` on pause.
Previously, on pause, the worker was let run and declare
layer gone 1/2 a second (or whatever the stream tracker window
is set for) later.
But, when rapidly changing mute/unmute, the following cuold happen
and layer changes may be missed
- Available layers - 0, 1, 2
- Mute
- Before layer gone detected, unumute. Because of this layer gone
is not reported and available layers stay at 0, 1, 2.
- Stream tracker is reset on unmute to enable quick detection of layer
start.
- If all layers start back up, no issues.
- But, if the layers do not start back up, there is no layer start
firing and the available layers are still 0, 1, 2 which is incorrect.
* exempt handling when paused
* Do not hold lock while invoking resolver.
Resolver is in room and it will grab its lock.
It is called from partcipant when checking permissions.
Permissions processing uses the participant lock.
So, not a good idea to call a room function with
participant lock held. Avoid that.
Also, use a full lock in the add/remove subscription
path. This is to ensure that permissions path and
subscription path (like subscribing to new participant's
tracks) do not race. As subscriptions are queued now
on the subscriber side, this should be fine.
* Revoke path resolution in ops queue goroutine
* fix test
* Keep track of pending subscriber operations.
This is required to determine if a receiver does not have
any subscription.
* correct spelling of queuing
* lock around hasPermission
* Move subscribe/unsubscribe queue to participant.
As subscribe/unsubscribe operation can come from both
local media track or remote media track, participant
needs to have it.
* Remove comment
* Stop reneg timer on close
* address comments
* Send permissions update on subscribe.
The permission `allowed` update was happening only when
processing pending subscriptions (which happens only on
subscription permissions update).
It is possible that subscription happens through other
paths (like subscribing new participant to tracks).
In that path, we were checking if the track has permissions
and adding to pending. But, we were not checking if
the track is in pending and if it is in there, removing
in on successful subscription and sending an update.
Fix that.
* log more fields in error
As there is a queue to send dynacast update, forcing
an update on unmute should be fine. That will send
the current state. If the subscribers change it,
an update will be sent as necessary.
This addresses the case of subscription changes happening
when the published track is muted. Dynacast updates are
not sent when publisher tarck is muted. If on unmute,
if subscribers do not have any changes, an update is missed
(i. e. the changes that happen when publisher track is muted
is not sent).
* Use a queue for add/remove subscribe operations.
If subscribe/unsubscribe happens very quickly, the subscription
state gets mixed up as things are keyed off of subscriberID.
Use a queue of subscribe operations and process it serially.
* set up callback for down track added
* move the queue on unexpected type
* move the queue if removeSubscirber does not have a subscribed track
With a small window, the quality is volatile even on small disturbances.
For example losing 2 audio packets in a 2 second window could
drop the quality metric.
* WIP commit
* Clean up
* spelling mistake
* Run subscribed track onBind in a go routine
* Address comments and more safety net
* Cache and restore forwarder state on resume
* conflicts
* mage generate
* Log reason for participant close
Please suggest better naming for different scenarios if something comes
to mind.
* group service requests
* incorporate feedback
* Change names in tests
