Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

livekit-client@2.22.4

Patch Changes

• Catch the rejection from negotiate() when the server requests media sections, so a failed renegotiation no longer surfaces as an unhandled promise rejection - #2108 (@SergeAx)

• Add disableIceLite connect option to request full ICE from a server running ICE lite. - #2085 (@subham2006)

• Fix Document Picture-in-Picture detection reporting opener-document elements as being in PiP. isElementInPiP compared an element's coordinates (computed within its own document) against the PiP window's viewport without checking which document the element belongs to, so while any Document PiP window was open, every observed video element positioned inside the PiP window's bounds - a tile near the top-left of the page, for example - was treated as in PiP. Because HTMLElementInfo.visible is isPiP || isIntersecting, those elements also counted as visible while scrolled out of view, which affected adaptiveStream subscription and layer selection. Detection now requires the element to live in the PiP window's document, or in a frame nested inside it. - #2106 (@dkelson)

• Ignore a duplicated server answer (same offerId) instead of applying it twice and surfacing a NegotiationError. - #2114 (@pblazej)

• Wait for the first video frame in waitForDimensions on iPadOS, which reports a desktop user agent - #2110 (@1egoman)

• Avoid attaching a new Closing/Restarting event listener for each negotiate call - #2084 (@1egoman)

• Wait for first video frame to be received before responding to waitForDimension on ios - #2100 (@1egoman)

• fix: wait for ReconnectResponse to arrive before declaring signal rec… - #2082 (@lukasIO)

• Retry against other LiveKit Cloud regions when the initial connection is rejected with 403. Cloud signals project-level region pinning with a 403 on the RTC paths, which was previously treated as terminal, so a client that geo-routed to a disallowed region never reached /settings/regions and failed to connect. 401 and the 404 "room does not exist" case remain terminal. - #2097 (@xianshijing-lk)

• refresh subscribed codecs after publisher answer - #2121 (@lukasIO)

• fix: expose participantIdentity on RoomEvent.DataReceived - #2092 (@mariusgassen)

• Fix track volume losing effect when set to 0 - #2111 (@robintown)

• Write the x-google-start-bitrate hint as a single connection-level value, once per publisher connection. - #2102 (@xianshijing-lk)

  libwebrtc reads this fmtp parameter per m-section but applies it to the shared Call (WebRtcVideoSendChannel::ApplyChangedParams → SetSdpBitrateParameters), where RtpBitrateConfigurator holds one config for the whole peer connection. Differing per-section values were therefore last-writer-wins on m-section order, so publishing a camera and a screen share together could seed the estimator from either one depending on SDP layout. Every video section now carries the same value: the largest hint among the sections that are currently sending.

  Only sending sections count. The list of registered track bitrates is append-only, and an unpublished section keeps its a=msid, so matching a section to a track by msid alone would still pair a stale entry with the section it used to occupy — letting an uncapped screen-share target seed a connection that now carries only a camera, or consuming the one-shot hint on a section that sends nothing, which would leave later publishes with no hint at all. The section's direction distinguishes them: a=recvonly and a=inactive cannot carry local media and are exactly where an unpublished or pre-populated section lands, while a=sendonly, a=sendrecv and an omitted direction all send.

  The hint is also written only on the first offer that carries local video, instead of on every offer. libwebrtc retains start_bitrate_bps and re-applies it on network route changes (RtpTransportControllerSend::OnNetworkRouteChanged), so rewriting it later is at best a no-op and at worst restarts a converged bandwidth estimator. A full reconnect builds a new peer connection and seeds the new estimator again.

  Targets below 300 kbps now get no hint, matching the Rust SDK: below that, seeding above the real capacity costs more than the ramp it saves.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.