Add e2e signalling tests - #1234
Merged
Merged
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
xianshijing-lk
approved these changes
Jul 13, 2026
xianshijing-lk
left a comment
Contributor
There was a problem hiding this comment.
lgtm, great tests.
Curious, any plans to add tests that verify media (audio / video tracks) as well? For example, making sure tracks are correctly restored after a successful reconnect, or verifying what happens when media negotiation fails?
lukasIO
marked this pull request as draft
August 21, 2026 13:02
lukasIO
removed request for
1egoman,
MaxHeimbrock,
cloudwebrtc,
jhugman and
ladvoc
August 21, 2026 13:02
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
lukasIO
force-pushed
the
lukas/signalling-spec
branch
from
August 21, 2026 13:05
b6df179 to
c273839
Compare
lukasIO
marked this pull request as ready for review
August 21, 2026 13:59
1egoman
approved these changes
Aug 21, 2026
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Contributor
Changeset ✓This PR includes a changeset covering all affected packages:
|
Merged
cloudwebrtc
pushed a commit
that referenced
this pull request
Aug 26, 2026
> [!IMPORTANT] > Merging this pull request will create these releases # webrtc-sys-build 0.3.19 (2026-08-25) ## Fixes - Automatically retry webrtc build downloads - feat: upgrade libwebrtc to m150. - #1284 (@cloudwebrtc) ### fix: bump libwebrtc to webrtc-b9233c3-2 so TURN/TLS can use the OS trust store WebRTC validates TURN/TLS against a small set of anchors compiled into `rtc_base/ssl_roots.h`, generated in 2023 from Google's own PKI list. It has no Amazon, Starfield Services or ISRG roots, so a relay-only connection to a TURN server fronted by AWS ACM or Let's Encrypt times out with `unknown_ca` even though the host OS trusts the chain. This build picks up webrtc-sdk/webrtc#277, which falls back to the operating system's trust store when the built-in anchors yield no path. It sits in `rtc_base` below every SDK, so the C++ API that webrtc-sys binds is covered without any Rust-side change. # livekit-api 0.6.4 (2026-08-25) ## Fixes - differentiate signal connection errors correctly from timeouts - #1234 (@lukasIO) - fix(uniffi): register the Bytes custom type once, in livekit-common - #1343 (@pblazej) ### Moves access-token generation and verification into a new `livekit-token` crate. `livekit_api::access_token::*` continues to resolve to the same types via a re-export, so no consumer changes are needed. Also fixes the `services-tokio` and `services-async` features, which used the access-token types without declaring the `access-token` feature. Building with `--no-default-features --features services-tokio` previously failed to compile. # yuv-sys 0.3.15 (2026-08-25) ## Fixes - yuv-sys: fail with an actionable error when the libyuv submodule is not initialized # libwebrtc 0.3.46 (2026-08-25) ## Features ### feat: enable WARP (SPED + SNAP) by default, gated by the server WARP is now always enabled on the client and negotiated with the SFU: SPED (DTLS-in-STUN) via the `WebRTC-IceHandshakeDtls` field trial, and SNAP (SCTP-INIT-in-SDP) via the `RtcConfiguration.enable_sctp_snap` field. When the server does not enable WARP it is not advertised and the connection falls back to plain DTLS/SCTP, so there is no client-side toggle. BREAKING CHANGE: `libwebrtc::RtcConfiguration` is now `#[non_exhaustive]` and has a new `enable_sctp_snap` field. Construct it from `RtcConfiguration::default()` and set the fields you need instead of a struct literal. ## Fixes - Automatically retry webrtc build downloads - feat: upgrade libwebrtc to m150. - #1284 (@cloudwebrtc) ### fix: bump libwebrtc to webrtc-b9233c3-2 so TURN/TLS can use the OS trust store WebRTC validates TURN/TLS against a small set of anchors compiled into `rtc_base/ssl_roots.h`, generated in 2023 from Google's own PKI list. It has no Amazon, Starfield Services or ISRG roots, so a relay-only connection to a TURN server fronted by AWS ACM or Let's Encrypt times out with `unknown_ca` even though the host OS trusts the chain. This build picks up webrtc-sdk/webrtc#277, which falls back to the operating system's trust store when the built-in anchors yield no path. It sits in `rtc_base` below every SDK, so the C++ API that webrtc-sys binds is covered without any Rust-side change. # webrtc-sys 0.3.43 (2026-08-25) ## Fixes - Automatically retry webrtc build downloads - feat: upgrade libwebrtc to m150. - #1284 (@cloudwebrtc) ### fix: bump libwebrtc to webrtc-b9233c3-2 so TURN/TLS can use the OS trust store WebRTC validates TURN/TLS against a small set of anchors compiled into `rtc_base/ssl_roots.h`, generated in 2023 from Google's own PKI list. It has no Amazon, Starfield Services or ISRG roots, so a relay-only connection to a TURN server fronted by AWS ACM or Let's Encrypt times out with `unknown_ca` even though the host OS trusts the chain. This build picks up webrtc-sdk/webrtc#277, which falls back to the operating system's trust store when the built-in anchors yield no path. It sits in `rtc_base` below every SDK, so the C++ API that webrtc-sys binds is covered without any Rust-side change. ### feat: enable WARP (SPED + SNAP) by default, gated by the server WARP is now always enabled on the client and negotiated with the SFU: SPED (DTLS-in-STUN) via the `WebRTC-IceHandshakeDtls` field trial, and SNAP (SCTP-INIT-in-SDP) via the `RtcConfiguration.enable_sctp_snap` field. When the server does not enable WARP it is not advertised and the connection falls back to plain DTLS/SCTP, so there is no client-side toggle. BREAKING CHANGE: `libwebrtc::RtcConfiguration` is now `#[non_exhaustive]` and has a new `enable_sctp_snap` field. Construct it from `RtcConfiguration::default()` and set the fields you need instead of a struct literal. # imgproc 0.3.20 (2026-08-25) ## Fixes - yuv-sys: fail with an actionable error when the libyuv submodule is not initialized # livekit 0.8.4 (2026-08-25) ## Features ### feat: enable WARP (SPED + SNAP) by default, gated by the server WARP is now always enabled on the client and negotiated with the SFU: SPED (DTLS-in-STUN) via the `WebRTC-IceHandshakeDtls` field trial, and SNAP (SCTP-INIT-in-SDP) via the `RtcConfiguration.enable_sctp_snap` field. When the server does not enable WARP it is not advertised and the connection falls back to plain DTLS/SCTP, so there is no client-side toggle. BREAKING CHANGE: `libwebrtc::RtcConfiguration` is now `#[non_exhaustive]` and has a new `enable_sctp_snap` field. Construct it from `RtcConfiguration::default()` and set the fields you need instead of a struct literal. ## Fixes - differentiate signal connection errors correctly from timeouts - #1234 (@lukasIO) - Automatically retry webrtc build downloads - feat: upgrade libwebrtc to m150. - #1284 (@cloudwebrtc) - fix(uniffi): register the Bytes custom type once, in livekit-common - #1343 (@pblazej) ### fix: bump libwebrtc to webrtc-b9233c3-2 so TURN/TLS can use the OS trust store WebRTC validates TURN/TLS against a small set of anchors compiled into `rtc_base/ssl_roots.h`, generated in 2023 from Google's own PKI list. It has no Amazon, Starfield Services or ISRG roots, so a relay-only connection to a TURN server fronted by AWS ACM or Let's Encrypt times out with `unknown_ca` even though the host OS trusts the chain. This build picks up webrtc-sdk/webrtc#277, which falls back to the operating system's trust store when the built-in anchors yield no path. It sits in `rtc_base` below every SDK, so the C++ API that webrtc-sys binds is covered without any Rust-side change. ### Moves access-token generation and verification into a new `livekit-token` crate. `livekit_api::access_token::*` continues to resolve to the same types via a re-export, so no consumer changes are needed. Also fixes the `services-tokio` and `services-async` features, which used the access-token types without declaring the `access-token` feature. Building with `--no-default-features --features services-tokio` previously failed to compile. # livekit-common 0.1.2 (2026-08-25) ## Fixes - Register the `Bytes` UniFFI custom type once in `livekit-common` and borrow it from each component with `uniffi::use_remote_type!`, so the converter is emitted once and the post-generation Swift workaround is no longer needed # livekit-token-source 0.1.2 (2026-08-25) ## Features - Adds optional caching version of the token sources # livekit-token 0.1.1 (2026-08-25) ## Fixes ### Moves access-token generation and verification into a new `livekit-token` crate. `livekit_api::access_token::*` continues to resolve to the same types via a re-export, so no consumer changes are needed. Also fixes the `services-tokio` and `services-async` features, which used the access-token types without declaring the `access-token` feature. Building with `--no-default-features --features services-tokio` previously failed to compile. # livekit-data-stream 0.1.3 (2026-08-25) ## Fixes - fix(uniffi): register the Bytes custom type once, in livekit-common - #1343 (@pblazej) # livekit-datatrack 0.1.14 (2026-08-25) ## Fixes - Register the `Bytes` UniFFI custom type once in `livekit-common` and borrow it from each component with `uniffi::use_remote_type!`, so the converter is emitted once and the post-generation Swift workaround is no longer needed # livekit-uniffi 0.1.9 (2026-08-25) ## Fixes - differentiate signal connection errors correctly from timeouts - #1234 (@lukasIO) - Expose `RemoteDataTrack.set_pipeline_options` and `RemoteDataTrackPipelineOptions` (`max_partial_frames`) over UniFFI, matching the JS and Rust SDKs - Register the `Bytes` UniFFI custom type once in `livekit-common` and borrow it from each component with `uniffi::use_remote_type!`, so the converter is emitted once and the post-generation Swift workaround is no longer needed ### Moves access-token generation and verification into a new `livekit-token` crate. `livekit_api::access_token::*` continues to resolve to the same types via a re-export, so no consumer changes are needed. Also fixes the `services-tokio` and `services-async` features, which used the access-token types without declaring the `access-token` feature. Building with `--no-default-features --features services-tokio` previously failed to compile. # livekit-ffi 0.12.76 (2026-08-25) ## Fixes - differentiate signal connection errors correctly from timeouts - #1234 (@lukasIO) - Automatically retry webrtc build downloads - feat: upgrade libwebrtc to m150. - #1284 (@cloudwebrtc) - fix(uniffi): register the Bytes custom type once, in livekit-common - #1343 (@pblazej) - Strip DWARF debug information from release iOS FFI archives. - yuv-sys: fail with an actionable error when the libyuv submodule is not initialized ### fix: bump libwebrtc to webrtc-b9233c3-2 so TURN/TLS can use the OS trust store WebRTC validates TURN/TLS against a small set of anchors compiled into `rtc_base/ssl_roots.h`, generated in 2023 from Google's own PKI list. It has no Amazon, Starfield Services or ISRG roots, so a relay-only connection to a TURN server fronted by AWS ACM or Let's Encrypt times out with `unknown_ca` even though the host OS trusts the chain. This build picks up webrtc-sdk/webrtc#277, which falls back to the operating system's trust store when the built-in anchors yield no path. It sits in `rtc_base` below every SDK, so the C++ API that webrtc-sys binds is covered without any Rust-side change. ### feat: enable WARP (SPED + SNAP) by default, gated by the server WARP is now always enabled on the client and negotiated with the SFU: SPED (DTLS-in-STUN) via the `WebRTC-IceHandshakeDtls` field trial, and SNAP (SCTP-INIT-in-SDP) via the `RtcConfiguration.enable_sctp_snap` field. When the server does not enable WARP it is not advertised and the connection falls back to plain DTLS/SCTP, so there is no client-side toggle. BREAKING CHANGE: `libwebrtc::RtcConfiguration` is now `#[non_exhaustive]` and has a new `enable_sctp_snap` field. Construct it from `RtcConfiguration::default()` and set the fields you need instead of a struct literal. ### Moves access-token generation and verification into a new `livekit-token` crate. `livekit_api::access_token::*` continues to resolve to the same types via a re-export, so no consumer changes are needed. Also fixes the `services-tokio` and `services-async` features, which used the access-token types without declaring the `access-token` feature. Building with `--no-default-features --features services-tokio` previously failed to compile. Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>
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
3 participants
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.
Before you submit your PR
Make sure the following is true before submitting your PR:
PR description
Describe the changes in this PR. Explain what the PR is meant to solve and how to reproduce the issue in the first place.
Breaking changes
If this PR introduces breaking changes, list them here and document the rationale for introducing such a change.
MSRV
If the PR modifies the crate's MSRV (Minimum Supported Rust Version), document it here.
Testing
Ideally, unit test the code you add, but ensure you're not repeating existing test cases. Use as many already written scaffolding, utilities as possible; write your own, when needed. If external services, APIs, tokens are required (e.g., running an LK server instance), provide the necessary information. Make sure your tests perform useful, context-aware assertions and do not simply emulate "happy paths".
Async
We want the project to be runtime-agnostic, so please reuse what's already in livekit-runtime and feel free to add anything missing. It's ok to use Tokio directly, when writing unit tests, if necessary. When testing, do not use artificial delays for the state to "catch up"; instead, respect the event flow and subscribe properly using channels or other mechanisms.