* Use a participant worker queue in room.
Removes selectively needing to call things in goroutine from
participant.
Also, a bit of drive-by clean up.
* spelling
* prevent race
* don't need to remove in goroutine as it is already running in the worker
* worker will get cleaned up in state change callback
* create participant worker only if not created already
* ref count participant worker
* maintain participant list
* clean up oldState
* Use Seque in ops queue.
Standardizing some uses
- Change OpsQueue to use Deque so that it can grow/shrink as necessary and
need not worry about channel getting full and dropping events.
- Change StreamAllocator and TelemetryService to use OpsQueue so that
they also need not worry about channel size and overflows.
* Address feedback
* delete obvious comment
* clean up
* Augment LeaveRequest with alternate regions to connect.
* update protocol and issue resume action on close if expected to resume
* use current protocol in tests
* address feedback
Used the full TrackInfo in my previous PR, but telemetry might be
relying on top level Width/Height. So, make a pared down TrackInfo to
report to telemetry.
Also, correct some spelling/comments.
* Unify muted and unmuted migration paths.
If dynacast had disabled all layers, after a migration, the client did
not restart publish (it is akin to muted track). That failed migration
because migration state machine waits for unmuted tracks to be published
(i. e. server has to receive packets).
If a migrating track is in muted state, server does not wait for
packets. It synthesises the published event and catches up later when
packets actually come in.
Just treating all migrations as the erstwhile muted case. Sythesise
publish whether track is muted or not. In the unmuted case, packets
might arrive soon after whereas in muted case, it will depend on when
unmute happens.
This is tricky stuff. So, will need good testing.
* use muted from track info
The comparisson between the last and current ParticipantInfo_State wasn't atomic. This sometimes resulted in two calls to onStateChange method for the same participant state. In the end this was reflected in two ACTIVE events being generated for the same participant at exactly the same moment. The fix actually uses the atomic method Swap to properly protect the "compare and set" operation and avoid any race condition.
* Add a simulation scenario to disconnect signal channel on resume
- Requesting that scenario add that participant to a map with a timeout
of 5 seconds.
- If a resume (reconnect = 1) happens before the timeout, the signalling
channel is closed immediately on resume.
- There is a clean up worker which will remove entries from the map when
they timout.
- The participant is also removed from the map if the disconnect on
resume is invoked once.
* simulate disconnect signal on resume no messages
* comment
* comment
* Close all retries
* update deps
* abort resume only if simulation applied
* Revert SIP change
PacketsLost may not provide useful if repairs are discounting the loss.
So, out-of-order packets are an indication of loss and maybe subsequent
repair. Note that out-of-order could be just out-of-order by a short
amount of time, but a lot of that happening is not good either.
So, out-of-order could provide a decent view of link quality.
* Prevent race of new track and new receiver.
Two different concepts
1. Creation of a new media track
2. Creation of a new receiver inside the media track
collided and caused track published to not be fired.
Unify to mark creation of new receiver as the source of truth.
With simulcast codecs, creation of a new receiver should be treated as a
new published track.
* Fire onTrackPublished only on new track
* Synthesise codec when adding pending track for no simulcast case also.
Older clients not using simulcast codecs were failing e2e migration
tests. Problem is that they did not have layer information and hence
SSRC could not be set on migration.
A codec was getting added later (when OnTrack was received). I missed
adding layers in that code. Could have cloned layers there and added it.
But, simplifying and adding at the start itself.
Also, cleaning up code in `MediaTrackReceiver` for no codecs case as it
should not happen any more.
* clone per layer
* fix priority determination
Previously, it was done on read. Missed populating it on write
in the TrackInfo consolidation effort.
Fix by populating layers when adding pending track itself.
As all codecs will have same layers, clone the top level layers and add
it all codecs.
* Consolidate TrackInfo.
TrackInfo was spread across a bit. Consolidating it.
* TODO comments
* test
* update TrackInfo on SSRC change
* further consolidation
* log mimes only
* update receivers on SSRC set
* clone proto on return
* feedback: break loop on mime match
* prevent data race
Need to store identity of other partiicpant in cache so that it
can be sent with the disconnected participant update.
Side note: Feels like the cache can be made to hold the full proto
to make things simpler, but just adding a field for now.
* Log cleanup pass
Demoted a bunch of logs to DEBUG, consolidated logs.
* use context logger and fix context var usage
* moved common error types, fixed tests
* Restrict scope of negotiation time out error logs
1. Log "negotiation failed" only if signal channel was active
within half window of negotiation timeout. Negotiation timeout currently
is at 15 seconds. Signal pings are every 10 seconds.
2. In transport.go, do not report negotiation timed out and do not
callback negotiation failure if the peer connection state is not
connected. Goal of negotiation failure tracker is to take remedial
action when an in-session negotiation fails. Seeing a bunch of cases
of the case hitting even without ICE connection forming. Negotiation
timer is not intended for those cases.
* fix test
* Add optional supervisor disable.
Used `DisableSupervisor` so that default can be enabled and
it can be disabled explicity. But, open to defaulting to disable
(i. e. change param to `EnableSupervisor`).
* Move nil check to call site
* Introduce `DISCONNECTED` connection quality.
Currently, this state happens when any up stream track does not
send any packets in an analysis window when it is expected to send
packets.
This can be used by participants to know the quality of a potentially
disconnected participant. Previously, it took 20 - 30 seconds for
the stale timeout to kick in and disconnect the limbo participant which
triggered a participant update through which other participants knew
about it.
Previously, `POOR` quality was also overloaded to denote that the
up stream is not sending any packets. With this change, that is a
separate indicator, i. e. `DISCONNECTED`.
* clean up
* Update deps
* spelling
