This ensures client reconnect attempts would be successful for long running rooms. It also fixes inaccurate permissions that were set incorrectly when full reconnections take place.
* Refactor media track subscriptions
- To enable re-use of common bits
- Add max quality from other nodes
* Lock close handlers slice
* Reverting multiple on close handlers of downtrack, unclear if it is needed yet
* Make Logger a pointer
* audio level in MediaTrack like remote media track
* Cleanup
* Add a no subscribers callback
* Add method to update subscribed quality from another node
* loss proxying from remote node
* Address comments from David
* create subscriber node quality map
* WIP commit
* update protocol
* Fixing a test and catching one place where casting was missed
* Fix one more spot which need conversion from livekit.RoomName -> string
* do not covert list
* WIP commit
* Add some tests
* allowedSubscribers uses participant sid
* correct variable name
* correct another variable name
* Add ParticipantSid to SubscriptionPermissionUpdate message
* protocol v0.11.2
* WIP commit
* WIP commit
* fix tests
* Remove unused code
* Close uptrack manager
* Remove duplicate close
* move comment to the correct line where the loop could be long
* Fix disallowed list revocation, thank you Jie
* Remove unneeded interface method
* RemoveSubscriber in Participant
* Clean up disallowed subscriptions and handle permissions on new track addition
* add test for track addition after permission set
* Remove unnecessary check
* Scoped speaker update
Include only participants a participant is subscribed to.
NOTE: Not doing this for active speaker changes for Protocol < 3.
* correct comment spelling
* audio connection quality mos for publisher stats
Signed-off-by: shishir gowda <shishir@livekit.io>
* Update tests
Signed-off-by: shishir gowda <shishir@livekit.io>
* Change ratings range, increase default rtt to 80
Signed-off-by: shishir gowda <shishir@livekit.io>
* Use stats worker to get total packets to find %lost in window
Signed-off-by: shishir gowda <shishir@livekit.io>
* Update go dep
Signed-off-by: shishir gowda <shishir@livekit.io>
* Increase interval of score cal to 5 seconds
Signed-off-by: shishir gowda <shishir@livekit.io>
* use lastSequenceNumber in reports to find total packets
Signed-off-by: shishir gowda <shishir@livekit.io>
* Account for delay while calculating scores
Signed-off-by: shishir gowda <shishir@livekit.io>
* Fix minor typo
Signed-off-by: shishir gowda <shishir@livekit.io>
* Add connection stats/score to subscribed audio tracks
Signed-off-by: shishir gowda <shishir@livekit.io>
* Cleanup
Signed-off-by: shishir gowda <shishir@livekit.io>
* Ignore duplicate LastSequenceNumbers in rtcp reports
Ignore if sequence number is less than what was recieved
Signed-off-by: shishir gowda <shishir@livekit.io>
* Move video track score calc to media/downtracks
Signed-off-by: shishir gowda <shishir@livekit.io>
* Deprecate SubscribeLossPercentage() as score calc is now handled downstream
Signed-off-by: shishir gowda <shishir@livekit.io>
* Initialize connection score to excellent
score is calc at 5sec interval. Client fetches score before first
score is computed
* Update test cases for connection quality
Signed-off-by: shishir gowda <shishir@livekit.io>
* WIP commit
* SubscribedQualityUpdate message to send list of currently subscribed
qualities for a simulcast video publisher
* Correct subscriberID
* goimports
* Do quality update on add/remove of subscribed track
* do not update quality when admin mute is active
* update quality on admin unmute
* Update protocol version
* Simplify max subscribed quality loop per David's suggestion
* WIP commit
* deficient handling
* Add missing ProvisionalAllocatePrepare
* adjust state on track removal
* Increase test timeout
* - Add comments about cooperative routines
- Take down transition if available in cooperative scheme
- Use layer comparison when taking down transition. Because of when the
bitrate is measured, it is not always guaranteed bandwidthDelta is -ve
when moving down.
- Do not add track to stream allocator till bind.
* make comment better
* a bit more clear comments
* Use OnBind on subscribed track
* Stream Allocator Try 3
Making an intermediate PR to do
- Special treatment for screen share tracks
- When allocating all tracks,
o try to stream all tracks by starting with the lowest layer
o multi-pass across tracks to get a more even distribution
Not yet done:
-------------
In deficient state,
o Allocate a specific track on a change
o Steal from other tracks
* Correct sense of managed track
* have to range to copy
* generate
* fix VideoLayers compare
* Use t.simulcasted
* Separate from ion-sfu
changes:
1. extract pkg/buffer, twcc, sfu, relay, stats, logger
2. to solve cycle import, move ion-sfu/pkg/logger to pkg/sfu/logger
3. replace pion/ion-sfu => ./
reason: will change import pion/ion-sfu/pkg/* to livekit-server/pkg/*
after this pr merged. Just not change any code in this pr, because it
will confused with the separate code from ion-sfu in review.
* Move code from ion-sfu to pkg/sfu
* fix build error for resovle conflict
Co-authored-by: cnderrauber <zengjie9004@gmail.com>
* Fix faulty participant update buffering.
* Fix bug with broadcasting out of order
* dedicated participant update worker, without locks
* use tracker to drop duplicate/out of date messages
* additional lock around filter logic
* Prevent missing entry in pending tracks
Problem:
--------
A track received via signalling request `AddTrack` is stored
in `pendingTracks` of participant. A MediaTrack is created
when `onTrack` fires after `SetRemoteDescription`. At that
time, pending tracks are searched to find a matching track
and look up an already published MediaTrack.
This is because `onTrack` fires once for every layer of
Simulcast and MediaTrack abstraction is for a media track and
not one for every layer of Simulcast track.
To accomplish that, pending tracks are cleaned up 5 seconds
after the MediaTrack is created. The theory there is that
`onTrack` will fire on all layers within 5 seconds. But, have
observed several instances on my slow machine of that firing
after 5 seconds which results in the search failing and we end
up creating a new MediaTrack.
The above is probably the reason (I am guessing though) for
subscriber PC having an extra m-line some times.
Considered fix:
---------------
One possible option is to increase that 5 seconds timeout to a
very large value. But, it has another issue.
`getPendingTrack` is given the track id which comes in the SDP.
Entries are added to the pending tracks using track id received
via the `AddTrack` signalling message.
And those two need not be the same. Especially Firefox has different ids
every time. Not sure if that is something we do on client side which
causes that, but it does look like a real possibility.
To handle that case, `getPendingTrack` looks up tracks by media kind
(audio/video) if the look up by SDP client id fails.
Here, it is possible that there are two pending tracks of type video
(think camera and screen sharing as an example) and looking up by kind
might end up picking the wrong one.
Fix:
----
Store the signalled client id and SDP client id in the MediaTrack and
look up the published tracks by SDP client id for a track match.
If there is no match, create a new MediaTrack and add it to publishedTracks
and delete the corresponding pending track all within the lock (yeah not
great to have a lot of code within the lock, but this is probably worth
it to have the correctness).
This does solve the issue of deferred pending track removal causing issues.
However, note that kind based look up may do some switching. In a scenario
where there are two pending tracks of kind video and the look up has to
rely on kind, it is possible that signalCid and sdpCid get cross matched
(i. e. client might have sent a signalCid for a Simulcast track, but during
kind based look up it gets assigned to a non-simulcast track). I think
that is okay as there is no strong correlation between the two.
Testing:
--------
- Connect from Chrome, Firefox (both orders, Chrome joining first, Firefox joining first) and ensure that media subscriptions and publishing are correct
- Ensure that DTX munging works properly too.
* Fix tests
Add back adding track to publishedTracks for testing purposes.
* Add a test to check case of `AddTrack` rejecting already published track
* Remove debug.
* Address PR comments - do not need to return SDP cid from `getPendingTracks`.
Raja Subramanian