A subscriber that requests the top spatial layer would briefly decode a
lower layer before settling on the requested one (e.g. layer 0 -> layer 2),
a visible low->high quality ramp. Two distinct causes:
1. Simulcast.Select latched opportunistically onto the first key frame of
any layer <= target, so a lower layer's key frame (which usually arrives
first) was selected before the requested layer's.
2. When the subscriber joined before the publisher started, the layers are
detected gradually and `maxSeen` climbs 0->1->2. AllocateOptimal caps the
target at `min(maxSeen, requested)`, so the target itself ramped up and
Select followed it.
The new behavior is gated behind a `LiveStreamingMode` Room config option
(default false -> original opportunistic behavior unchanged):
- Select latches directly onto the target layer during initial acquisition.
- Forwarder gains an initial-acquisition grace: while not yet streaming and
the requested layer has not been seen, the target/key-frame-request aim
straight at the requested layer instead of the highest seen so far. Gated
on `maxSeen < requested` so steady-state behavior (incl. overshoot) is
unchanged.
- If the requested layer never shows up within the grace, the key frame
requester triggers a re-allocation so the target falls back to the highest
layer actually seen, avoiding a stall/black screen.
- On bind, a live-streaming subscriber requests the highest layer up front
(instead of the adaptive-stream LOW start) so it is acquired directly.
LiveStreamingMode is threaded from config.RoomConfig through the participant
(GetLiveStreamingMode) and SubscribedTrack/DownTrack params into the Forwarder
and Simulcast layer selector.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Update go deps to v4
Generated by renovateBot
* update dockertest to v4
* fix
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: David Zhao <dz@livekit.io>
MoveToRoom resets the participant reporter resolver to receive new
(room, participant_session) keys for the destination, but the source
room's participant_session row never gets an end_time — the periodic
duration scrape only emits one once disconnectedAt is set, and a move
doesn't transition the participant to DISCONNECTED. Report end_time
immediately before the reset so the row is closed out cleanly.
* Metrics for participant active, i. e. fully established.
- Egress stub for v2 API
- Fix the participant canceled counter 🤦
- Add active counter -> this is increment when a participant becomes
active, i. e. primary peer connection established. Can be used to
monitor node wise connection establishment issues.
- Add singnalling validation fail counter.
With this, we have
- signalling validation fail
- signalling failed --> this is when the `startSession` fails
- signalling connected -> signalling is succesful and can send back
joinResponse to client
on media connection side
- rtc_init -> start
- rtc_connected -> participant session created (joined)
- rtc_active -> primay peer connection established
- rtc_canceled -> could not proceed with RTC connection due to not being
able to resume.
* signalling counters deps
* revert pion/webrtc to 4.2.12 to get SCTP without interleaving
* go back to pion/webrtc 4.2.11 and sctp 1.9.5
* telemetry: split webhook-processed hook registration out of NewTelemetryService
NewTelemetryService used to register a notifier processed-hook on the inner
*telemetryService directly. That made it impossible for downstream wrappers
(e.g. cloud's TelemetryService that overrides Webhook to fan out to a v3
observability pipeline) to intercept webhook events without double-firing
the legacy emission.
Lift the registration into a new exported helper RegisterWebhookHook, and
have the standalone server's wire provider createTelemetryService call it
right after construction so behavior is unchanged for callers that don't
wrap the service.
When a client hits /rtc/v[01]/validate with a base64 WrappedJoinRequest
whose embedded JoinRequest.ClientInfo is unset, validateInternal called
AugmentClientInfo with a nil *ClientInfo and panicked at ci.Address =
GetClientIP(req). The non-wrapped branch already allocates via
ParseClientInfo; do the same here so pi.Client always gets at least the
resolved client Address.
Data tracks (the new _data_track datachannel) previously only updated a
private dataTrackStats that logged a single summary at Close. Bytes never
reached the OnTrackStats -> TelemetryService.TrackStats pipeline that
media tracks and signal channels feed.
Wire DataTrack (UPSTREAM, publisher-home) and DataDownTrack (DOWNSTREAM,
per-subscriber) into BytesTrackStats on the same 5s cadence, mirroring
the media-track convention: subscriber's country and ID with publisher's
track ID for DOWNSTREAM. Cross-region proxy DataTracks leave the stats
pointer nil (no publisher reporter on that node, and relayed bytes would
double-count). Legacy dataTrackStats packet-loss/frame counters are
preserved.
Shared helper for callers that need to distinguish intentional/expected
participant closures (client leave, admin action, room teardown, migration)
from connection failures. Extracted from cloud's IsClosedIntentionally
switch so cloud-side code paths can share a single source of truth.
Reverting
- https://github.com/livekit/livekit/pull/4521
- https://github.com/livekit/livekit/pull/4525
There are TWCC feedback packets that are larger than MTU. Seems to
happen under a couple of conditions
1. Bad client data, i. e. severely out-of-order packets, bad sequence
numbers, etc.
2. On an ICE restart - this is rare, but it seemed to be flaky network
with some packets arriving and some not and causing a lot of gaps.
Either case, not much to do. If fargmentation/re-assembly back to
publisher works, the feedback will make it through. If not, feedbacks
will be missed and clients have to work with some missing data which is
not unexpected and the protocol is designed to handle.
However, filed pion/interceptor issue just in case - https://github.com/pion/interceptor/issues/416
* Don't require media sections when joining
Client except browser (rust/libwebrtc is known) could have problem
to fire ontrack event when reuses extra media section to subscribe
track, so disable this feature in server side and let client determine
if extra media sections are needed.
* lint
* rtc: report participant kind code and details
Plumb ParticipantKind and KindDetails through MediaTrack and
BytesTrackStats so track-level reporting can record the numeric kind
code plus details codes on every participant_session aggregation,
alongside the existing Kind string. Also picks up the new kind fields
on resolved BytesSignalStats participants.
Adds deployment/agentID/version to the agent worker logger.
Sfu will fallback to retransmit packet by media stream ssrc if rtx
is not negotiated (client doesn't have), so we should not disable
rtx explicitly (by codec config).
Fix#4519
* Release v1.12.0
Please read the note in the release about TURN related changes and let
me know if it is clear enough that projects should update and prepare
for backwards compatibility removal in the next release.
* space
Not a major issue, but just avoiding duplicate creation of NACK module.
RTCP feedback of `nack` and `nack pli` end up getting treated as `nack`
and was double creating.
* Apply ttl check only when authenticate allocation creating
TTL check could reject allocation/persmission refresh in
security enhancement #4505, cause long-live session disconnect
when turn credential is expired.
Only check ttl on allocation creating to prevent abusing leaked
credential but keep long-live session work.
* Log details of RTCP packets.
Seeing large (> MTU) packets on publisher peer connection RTCP. The
four types there are
- RTCP Receiver Reports
- NACK
- TWCC
- PLI
Can't think of what would be blowing up in size.
RTCP Receiver Report and PLI are fixed in size
NACKs vary, but the limit is 100 NACKs which should fit in 400 bytes
even if all of them are spread apart in the sequence number space.
TWCC varies, but a feedback packet is sent every 100ms or when it holds
100 packets. So, that also should not be too big.
Logging packet details to understand this better.
* revert debug
* Add integration test for TURN auth failures
Covers four credential-corruption scenarios against the TURN server
embedded in a single-node server: unparseable username, wrong password,
expired username, and unknown API key. Each case drives a raw pion
turn.Client Allocate and asserts the server rejects with a TURN error.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* TURN auth test: cover password expiry binding
The TURN password's hash includes the expiry along with the secret and
participant ID. Add two cases that exercise this binding: a password
generated for a different expiry than the username's, and a password
generated without any expiry component paired with a username that has
one.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Log large packets receive/send.
Seeing cases of servers reporting need for segmentation/re-assembly of
packets. So, logging packet receive/send for RTP/RTCP to check if
anything is seeing more than 1400 byte packets.
* log downtrack RTCP too
This patch updates the check for auto creating rooms to also
consider the RoomCreate grant per token instead of just the
global config option.
With this patch, applications can decide on their own whether
users or which users can auto create rooms. This allows
applications that rely on auto creation (saving an API call)
to co-exist with those who might want to mint tokens for
subscribe-only users.
Specifically LaSuite Meet relies on the auto create behavior,
however enabling the global config option would make a
MatrixRTC deployment vulnerable to abuse, as users on remote
homeservers get tokens in order to subscribe.
* add AssignmentHook to AssignJob; propagate websocket write errors
- Replace the `url *string` parameter on `Worker.AssignJob` with a
middleware-style `AssignmentHook` so callers can intercept the
`JobAssignment` send (e.g. to set Url, or to gate hedged attempts so
only one assignment is written).
- Remove the `sendRequest` helper. Inline `WriteServerMessage` and
propagate the error: `AssignJob` returns immediately on a failed
availability or assignment write, leaving the job out of
`runningJobs`; `TerminateJob` still updates local bookkeeping when
the wire write fails but surfaces the write error to the caller.
* tidy
* Add TURN permission handler.
- Turn off permissions to private/link local/multicast and internal IPs
- Add a list of CIDRs that can be used for more things to deny
permission to.
* unused
* add config for allowing private IPs, used in testing
* add a TTL to user name and use it to auth
* allow list for restricted peer CIDRs
cloudwebrtc