Repository navigation
feat(rtc): add LocalParticipant.send_bytes - #858
Merged
Merged
Conversation
Expose the FFI's existing one-shot byte stream send (StreamSendBytesRequest) in Python, mirroring send_text / send_file. Because the whole payload is known up front, short payloads go out as a single inline packet and larger ones are deflate-compressed when every recipient supports data streams v2 — something the incremental stream_bytes writer can't do. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Draft
2 tasks
1egoman
marked this pull request as ready for review
October 11, 2026 23:26
1egoman
requested review from
changt,
cloudwebrtc,
lukasIO and
xianshijing-lk
as code owners
October 11, 2026 23:26
cloudwebrtc
approved these changes
Oct 12, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Introduces a new
LocalParticipant.send_bytes(data, *, topic, name, mime_type, destination_identities, attributes, stream_id, compress)method, the byte-stream analogue ofsend_textand the in-memory analogue ofsend_file.The FFI already implements this (
StreamSendBytesRequest, handled bylivekit-data-stream'ssend_bytes); it just wasn't exposed in Python. Because the whole payload is known up front, it means the Rust side can:Neither is possible through the incremental
stream_byteswriter, which always sends header + chunk(s) + trailer uncompressed. That makessend_bytesthe right primitive for small, frequent messages.Background info
This is being added now because I did some benchmarking and still noticed quite a bit of rtc data channel congestion even with rpc v2, data stream v2, and transcription deduplication. After digging in, it looks like the cause was the
RoomSessionTransportfromlivekit-agents- it sends quite a fewlk.agent.sessionevents, each as its ownstream_bytesstream.Measured against a JS client (client protocol 3, with transcription deduplication enabled), one agent turn produced ~92 such streams, each 3 packets. Switching that call to
send_bytescut the client's per-turn data channel traffic from ~52 KB / 354 messages to ~37 KB / 170 messages (−29% bytes, −52% messages). On constrained mobile network links, that decrease in bytes results in decreased queue pressure in front of RPCs and transcriptions, which is a big reason why data streams v2 were introduced in the first place.Testing
test_send_bytes_small(hello-world round trip +ByteStreamInfoassertions). It fails on the current release (AttributeError) and passes with this change, alongsidetest_send_text_smallandtest_send_file_round_trip.ruff check/ruff format --check(pinned 0.15.4) clean;mypy -p livekit.rtcadds no new errors.