This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

saw this message in the socket at one point:

This message was deleted.

This message was deleted.

This message was deleted.

Hey folks - I'm looking to use a livekit backend with a Unity front -end. I'm debating which path to go down and maybe you can help provide some guidance: Path 1 - Use

client-sdk-js

in an embedded browser for signaling, but unity-webrtc for media, creating offer, ice candidates, etc. • Pros: ◦ Don't have to maintain parity with a changing client-sdk-js repo ◦ Reduces dependencies in my Unity project (protobuf, websocket, etc.) • Cons: ◦ I must communicate with the browser via javascript events and build out this communication layer (not too hard) ◦ The heavy lifting in livekit signaling (RTCEngine + Room) seem to be coupled to browser webrtc. On quick glance I see RTCConfiguration, MediaStreamTracks, and direct calls to the PeerConnections • Ideally for this strategy to work: ◦ The ideal case here for me would be that entities interacting with the the meat of livekit would be interfaces and I could create my own versions of them. Unity webrtc will give me the offers and the ice candidates for cameras + unity audio tracks that I specify. Path 2 - Reimplement livekit client in c# • Is there a state/flow diagram I can reference for this? I'm having a hard time wrapping my head around it.

Hi Neil! I think Path 1 is likely going to be fairly hacky.. and you'd have to rely on a one to one mapping between Unity webrtc to browser webrtc (even if we find a way to shim them for Unity)

I think Path 2 is likely to be the best approach. LiveKit signaling is pretty simple.. (tho not well documented). I'm happy to help you get through it too! (especially if you are interested in making it OSS)

Yeah for path 1 I was sort of thinking there was a 1:1 mapping with the connection parts of webrtc and to just build a faux-peer connection that proxied through all of the offers and ice candidates and whatever else to unity. But yeah looking through the code I think this would be difficult without a pretty sizeable refactor of the livekit client and I doubt that'd be worth it for you all ;) Sounds good - path 2 it is! I'd be interested in OSS for sure although for now I'd like to derisk it first just from a feasibility standpoint. I was able to get your protobufs built and working and a ws signal client that's basically a 1:1 c# rewrite. When I looked at the RTCEngine is when I got spooked because it seemed to have some opinion on media tracks

I think using the iOS client would be a better template than JS, RTCEngine is essentially the glue between signal client and peerconnection

ahh yeah that makes total sense, I bet the ios one is pretty similar

let me see where I get today - thanks for the advice! livekit + unity is about to be incredible 🙂

I'll write a bit more docs on the flow & protocol, will share them with you!

yah! I'm excited. Looks like Unity webrtc is a newish effort that they are serious about.

yeah - android support literally last month haha. I'm working on oculus quest so I was waiting for that

This message was deleted.

oh this is great, thanks!

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.