* Add a trend check before declaring joint queuing region.
Seeing cases where the propagated queuing delay drops from one group to
next. Both groups are above threhold. It also recovers majority of the
time. So, introducing a trend check before declaring that queuing delay
is in joint queuing region. It is set 0.8 by default which means the
queueing delay should be trending up strongly before being declared
joint queuing region.
* deps
* Make sure moving out track has been unsubscribed
Remove start time checking in subscription manager
as We always use new track ID for republished track at #3020
so there is no race condition now.
Also RemoveSubscriber for moving out tracks for safety,
the subscription manager will handle the removed event but
RemoveSubscriber again will not be bad.
* Clear subscriber node max quality for moving out tracks
* Send initial participant update only after a participant becomes active.
There are cases where apps send data to remote participant as soon as
client emits `ParticipantConnected`. But, that time point would not have
a fully established client (i. e. the media connection + data channel
establishment is still in progress).
This PR changes the initial participant update to be sent from server
side only when a participant becomes `ACTIVE`, i.e fully connected
(media channel established and data channels open).
It is supported for clients using protocol version > 15.
@cnderrauber bumping up the protocol version in this PR. Move support is
also conditioned on protocol version > 15, but that PR did not ump
protocol version. Please let me know if there are issues bumping
protocol version.
* check for joining states in broadcast
* have to check on other participant
* test
* make helper for sending participant updates
* test
* make utility of pushAndDeque
* test
* consolidate getting other participants
* remove extra cast
* debug
* debug
* typo
* stop transceiver that is not bound
* logs
* log
* check for ever bound
* clean up
* clean up
* Add Moving participant to another room
it is implemented in cloud only since the destination
room can exist in different node with the source room
* Update pkg/service/errors.go
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* rename
* test panic
* fake LocalParticipantHelper
* revert delete line
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Call Broadcast in lock scope.
Seems like there is a possible window where things can hang forever
if a goroutine enters the Wait) after the lock is released but before
Broadcast gets called, it will never see that broadcast and will hang forever.
* RLock
This patch ensures that SIP headers provided in TransferSIPParticipantRequest requested by an agent are correctly forwarded to the internal SIP transfer request.
Previously, req.Headers was accepted but never passed along, causing headers from the initiating agent to be dropped.
This change adds a single line to include req.Headers in the internal request.
Tested with eyevinn client.
There are a few issues to figure out still
1. Simulcast - how?
2. For simulcast, how to know width, height so that adaptive stream can
work.
3. The layer added is dummy. It works, but connection quality scoring
would be incorrect (will always say excellent) without bitrate.
Will need some dynamic update of `TrackInfo` based on actual stream for
all of this to fit well into our system, but the simple video support
works for now.
Was setting the state to ACTIVE prematurely to enable the subscription
inter-lock in one shot signalling mode. But, that is incorrectly
changing state.
Use a callback to indicate subscriber ready and let the participant
ACTIVE happen when the connection actually establishes.
Had made the change to align `participant active` to after the ICE
connection is done and that log could list all candidates.
But, with one shot signalling, the state change has to be early to wait
on (auto) subscriptions of track of other participant. So, state has to
be changed early.
