Bridge: RpcController by stephen-derosa · Pull Request #67 · livekit/client-sdk-cpp

stephen-derosa · 2026-02-27T20:38:47Z

Overview

RPC Controller for handling built in RPC calls and user registered RPC calls.

Built in RPC calls

mute/unmute tracks on remote participants

Examples

examples/bridge_mute_unmute/
examples/bridge_rpc/

Testing

RPC application level integration tests
RpcController unit tests
testing through examples

include/livekit/track.h

include/livekit/local_participant.h

src/ffi_client.cpp

bridge/src/rpc_manager.h

bridge/src/rpc_controller.cpp

bridge/src/rpc_manager.h

xianshijing-lk · 2026-03-07T02:00:26Z

I think we are on the right track. some more questions

xianshijing-lk · 2026-03-07T02:21:39Z

bridge/include/livekit_bridge/livekit_bridge.h

+   * @param handler      Callback invoked on each incoming invocation.
+   * @return true if the RPC method was registered successfully.
+   */
+  bool registerRpcMethod(const std::string &method_name,


RpcMethod is pretty low level, I wonder if we should make a remote controller, and we will setup a remoteControlInternal method as the communication channel for the remote control

im not sure i understand the need to break this into another layer. My intention here was to have a single object (currently RPCManager) which does all the interfacing with the local participant required to register/make/receive RPC calls. I wanted to keep the function of registerRpcMethod here the same as it is in the local participant for clarity.

who is going to call this registerRpcMethod() ? like developers ? or it will be called by your RpcController / RpcManager ?

a developer in their application would call: livekit_bridge->registerRpcMethod("my-awesome-rpc", awesome_rpc_handle) which simply wraps around the RpcController

RPCManager: bridge object for managing default and custom RPC calls bridge_rpc examples RPCManager tests requestTrackMute/Unmute -> requestRemoteTrackMute/Unmute . Make the trackActionFn action input an Enum add spdlog to docker and github actions

xianshijing-lk · 2026-03-13T08:30:34Z

bridge/include/livekit_bridge/livekit_bridge.h

+   * @param handler      Callback invoked on each incoming invocation.
+   * @return true if the RPC method was registered successfully.
+   */
+  bool registerRpcMethod(const std::string &method_name,


who is going to call this registerRpcMethod() ? like developers ? or it will be called by your RpcController / RpcManager ?

xianshijing-lk · 2026-03-13T08:38:05Z

bridge/include/livekit_bridge/livekit_bridge.h

+   * @param method_name  Name of the RPC method to unregister.
+   * @return true if the RPC method was unregistered successfully.
+   */
+  bool unregisterRpcMethod(const std::string &method_name);


I just want to raise the flag again:
At a high level, LiveKitBridge is trying to be too many things at once:

SDK lifecycle manager

room/session manager

local track factory + owner

remote track subscription router

frame delivery runtime

RPC client/server

remote track control plane

That makes the API convenient initially, but it creates tight coupling, unclear ownership, and many hidden behaviors that are hard to reason about in production.

I think convenience is a good reason to break object design. This livekit_bridge is getting to a super class that does everything. and once developers find the in-sufficience of current APIs, you will either need to move the missing APIs to this class, or ask the developers to get back to the base room APIs.
Either way will not give a good developer experience.

I'd love to hear your thought here.

I appreciate the raise here. The bridge is doing a lot i agree, most of it is boilerplate that i dont think new users dont really want wrestle with (Though your points about AI playing a role in development are not lost on me). My intention was in fact to support and build into the bridge whatever things may have been overlooked or needed by customers with the hope that it will cover the 90% use case for our customers. Id be curious to talk to our whale customers and see what their fine tuned control usage is. Im curious why you say that moving missing APIs (ideally we release with 1:1) to the SessionManager is a bad dev-X -- just simply because it doesnt exist?

The trade off between ease of use and loss of control is real, and If im wrong on the SessionManager because it sacrifices too much control or adds confusion thats ok. Im happy to make it an ugly step child of the SDK as i will definitely want something like it for the ROS2 bridge. One data point i will share from my experience and talking with other robotics developers who have used similar libs such as libdatachannels -- one of the first things done was some sort of manager which handles lifecycle of the SDK/objects and made registering callbacks/creating tracks trivial. (its the same reason i want it for the ROS2 bridge) Granted, my pool of users came from the ROS1/2 world so we may have just been subconsciously trying to align APIs.

My intention was in fact to support and build into the bridge whatever things may have been overlooked or needed by customers with the hope that it will cover the 90% use case for our customers. Id be curious to talk to our whale customers and see what their fine tuned control usage is.

I think it is a good idea, can we identify a couple of customers and we can start talking to them ?

Im curious why you say that moving missing APIs (ideally we release with 1:1) to the SessionManager is a bad dev-X -- just simply because it doesnt exist?

The concern I have is something like this:
Developers may find that certain APIs are missing from SessionManager, file feature requests, and then the team needs a few days to surface those APIs through SessionManager, plus another day or two to cut a release. This development loop could repeat for each customer who needs more control for their use cases.
Over time, developers might end up switching back to the lower-level Room APIs anyway. Alternatively, we might gradually expose most of the low-level APIs through SessionManager. At that point, it becomes harder to justify what SessionManager is actually abstracting.

The trade off between ease of use and loss of control is real, and If im wrong on the SessionManager because it sacrifices too much control or adds confusion thats ok. Im happy to make it an ugly step child of the SDK as i will definitely want something like it for the ROS2 bridge.

Got it. I think it is a reasonable approach to explore new APIs. It will be great if we can come up with some approach to measure the usage, but if we can't, it is OK that we will ask our developers.

I know we are coming back and forth, but Ben seems to have special vision on the session APIs, which will be focusing on agent use cases and abstraction of transport.
Maybe we should rename the session_manager to something specific to robotic use cases for now ?

thanks for the replies -- ill start getting the ball rolling about conversations once customers start using the cpp sdk since i dont think they'll even likely be able to speculate.

I am also concerned with the livekit_bridge adding a bit of slop in the development process. Hopefully having customers use the SDK we'll get a good understanding of what the 95% use case is!

Im happy to keep the livekit_bridge name, to avoid overloading session.

xianshijing-lk · 2026-03-13T13:11:32Z

bridge/include/livekit_bridge/livekit_bridge.h

                               const std::shared_ptr<livekit::Track> &track,
                               VideoFrameCallback cb);

+  /// Execute a track action (mute/unmute/release) by track name.


just found that you are expecting the users to call release for the tracks explicitly ?

aren't tracks managed ?

users have the option to release tracks in the case they want to release a track before disconnecting. But in the case a disconnect happens, the track will be release by the manager.

that being said, these RPC calls are to enable a remote participant to request mute/unmute of another remote participant.

bridge/include/livekit_bridge/rpc_constants.h

xianshijing-lk · 2026-03-13T13:23:59Z

bridge/include/livekit_bridge/livekit_bridge.h

+   * @param track_name            Name of the track to mute.
+   * @return true if the track was muted successfully.
+   */
+  bool requestRemoteTrackMute(const std::string &destination_identity,


These APIs are very concerning and can be very confusing.

What if the remote participant is not a livektiBridge (or SessionManager after the rename )?

How do you make sure these actions are backward compatitable ?

These built in RPC calls only work from session manager to session manager, since the RpcController belongs to the session manager. Of course users can register their own remote track mute/unmute RPC methods!

stephen-derosa requested review from chenosaurus, ladvoc and xianshijing-lk February 27, 2026 20:38

stephen-derosa self-assigned this Feb 27, 2026

stephen-derosa added the enhancement New feature or request label Feb 27, 2026

stephen-derosa commented Feb 27, 2026

View reviewed changes

include/livekit/track.h Show resolved Hide resolved

xianshijing-lk reviewed Mar 5, 2026

View reviewed changes

stephen-derosa force-pushed the sderosa/bridge-rpc branch 2 times, most recently from e38dd58 to 3237ad6 Compare March 5, 2026 16:51

xianshijing-lk reviewed Mar 7, 2026

View reviewed changes

stephen-derosa changed the title ~~Bridge: RPCManager~~ Bridge: RpcControlle Mar 10, 2026

stephen-derosa requested a review from xianshijing-lk March 10, 2026 17:23

stephen-derosa changed the title ~~Bridge: RpcControlle~~ Bridge: RpcController Mar 10, 2026

stephen-derosa force-pushed the sderosa/bridge-rpc branch from b6cfa19 to 967a37b Compare March 10, 2026 21:43

xianshijing-lk reviewed Mar 13, 2026

View reviewed changes

stephen-derosa added 2 commits March 18, 2026 18:49

cleanup comments

92a4347

cleanup comments

98c595e

stephen-derosa requested a review from xianshijing-lk March 19, 2026 00:57

Conversation

stephen-derosa commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Built in RPC calls

Examples

Testing

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

xianshijing-lk commented Mar 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

stephen-derosa commented Feb 27, 2026 •

edited

Loading