initially.
Out-of-order reception is detected and dropped before this change. By
moving the adjustment to that point, potentially more reports can be
processed.
TrackSubscribed is meant to give publishers an indication when the subscriber
is ready to receive its audio. When there are hidden recorders in the room,
we do not want them to trigger this event.
My previous PR was trying to fix a premature transition from CONGESTED -> NONE state.
But, that introduced a bug which accelerated the transition from EARLY_WARNING -> CONGESTED state due to holding the `queuingRegion` state variable.
Fix by not holding `queuingRegion` in state and take result of
processing runs.
NOTE: This can still use some work to make the state machine cleaner.
Initially, I was passing around a bunch of variables which was uncouth.
Then moved things to state which made code easier to read and also log
different things, but it causes problems like the ones above. Will take
another look and think more about making it more robust.
* Use nonce in data messages to de-dupe SendData API.
With API retries, it is possible that some data messages are sent
multiple times. Check the nonce (if present) to de-dupe data messages
before forwarding it to the clients.
* add nonce to UserPacket
* defer unlock
* 128-bit UUID as nonce
* - UUID nonce
- make a UserPacketDeduper module for easier re-use.
* deps
* feedback
* Resolve newer participant using higher precision join time.
Also, keep it consistent based on participant SID if everything else is
the same.
* switch to compare semantics
* fix
* Do not seed if stream is already writable.
It is possible that in migration case, when the forwarder state is
fetched from migrating out node and used to seed downtrack, it has
already started due to the time it takes to get the state. Seeding in
that state will reset things and cause large sequence number gaps
potentially.
* do not take lock
* Debug FF TWCC
* - TURN off TWCC for Firefox. Seems to fail with VP9 send, i.e. there are
no TWCC feedback packets when sending VP9.
- Relax thresholds for congestion as staging data is showing
oscillations.
- Clean up some logging.
* debug log a few more signal messages
* revert config
* revert config
* clean up
Seeing some negative loss count (seems to be when interacting with
Firefox, but don't have definitive proof it does not happen with
others). Debug logging a bit to understand what could cause it.
Also, consolidating some common code to process packet feedback.
* move unrolled mime type check for broader use
* Use in IsSvcCodec and make MimeType exported
* test
* tidy branches
* tidy
---------
Co-authored-by: Paul Wells <paulwe@gmail.com>
* Remove alloc in packet forwarding path.
Unlikely logger creation was doing allocs. Replace it with a function
like in rtpstats_receiver.go so that allocations do not happen
unnecessarily.
* variable rename
* one more place
