Repository navigation
Conversation
Port of livekit/rust-sdks#1527. Bumps the client protocol to 18 and creates the publisher data channels with fixed SCTP stream IDs (100/101/102) when the server supports it, falling back to in-band channels against older servers or in dual PC mode. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: fcb7d70 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
Devin Review found 1 potential issue.
1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)
| private useNegotiatedDataChannels() { | ||
| return ( | ||
| this.pcManager?.mode === 'publisher-only' && | ||
| (this.latestJoinResponse?.serverInfo?.protocol ?? 0) >= PROTOCOL_NEGOTIATED_DATA_CHANNELS | ||
| ); |
There was a problem hiding this comment.
🔴 Publisher data stops after server downgrade
When a session resumes on an older server, useNegotiatedDataChannels changes its verdict but leaves the negotiated channels open. The older server never receives their DCEP OPEN, so published data stops reaching it.
Learn more
A single-PC session with negotiated channels keeps its peer connection during signal resume. The resume response replaces latestJoinResponse.serverInfo, but channel recreation only runs for an open channel with a null ID in resumeConnection. Negotiated channels have fixed non-null IDs, so a resume onto a pre-18 server leaves them unchanged. That server does not use the fixed negotiated IDs and receives no in-band channel open message, while the client continues sending through the old channels.
Example: A client joins a protocol-18 server using negotiated ID 100 for reliable data. Its signaling session resumes on a protocol-17 server. The response updates the protocol to 17, but the client continues sending reliable packets on ID 100 instead of opening an in-band channel.
Recommended fix: On resume, compare the active publisher channel mode with the new server's protocol before completing reconnection. If it changed, replace the channels with the appropriate type and wait for the replacement to open; handle queued reliable messages and sync-state channel IDs during this transition.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
a session resume is not expected to land on an older version.
size-limit report 📦
|
Bump @livekit/protocol to 1.53.0, which defines NegotiatedDataChannelID, and drop the local ID constants. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
1 participant
In single peer connection mode, the server cannot send data until the client's data channels finish the in-band open handshake. The client creates
_reliable,_lossyand_data_trackas in-band channels. Each one opens with a DCEP OPEN message from the client. The server must wait for that message before it can send on the channel. That costs about one round trip of server-to-client readiness on every connect.This change creates the three publisher channels as negotiated, with fixed SCTP stream IDs 100, 101 and 102. The server uses the same IDs (livekit/livekit#5017, livekit/protocol#1871), so both sides can send right after SCTP connects. The client protocol goes to 18. The client uses negotiated channels only in single PC mode against a server that reports protocol 18 or higher. Dual PC keeps in-band channels, because there the server opens its own channels. This is a port of livekit/rust-sdks#1527.
The failure case is an older server on the offer-with-join path. There the client builds its first offer before it knows the server protocol. It creates negotiated channels optimistically. If the join response reports protocol 17 or lower, the client closes them and opens in-band channels with the same labels. The SCTP section is already in the offer, so this needs no renegotiation. The Firefox deferred path creates the channels after the join response, so it picks the right kind directly.
Impact
The saving is one DCEP round trip before the server can send on a fresh connection. It is not measured yet.
The IDs come from the
NegotiatedDataChannelIDenum, so this also bumps@livekit/protocolto 1.53.0. Against servers below protocol 18, the channels stay in-band and behavior does not change.🤖 Generated with Claude Code