This message was deleted.

Questions too weird? 😀

Neil, it's not a bother. But please understand that we have limited time in the day to respond to all the messages that are coming through. As it is a open Slack, messages do slip through and we can't promise any sort of SLA on responses. Reading your message, it's not entirely clear the specific points that you are blocked on. Of course, we would be glad to point you towards the right direction should LiveKit be a good fit for your use case.

Thanks. I understand that. I’m not blocked at all. I just wanted to get some insight beforehand

I'll try to answer what I can. re: data channel, we expose a pretty flexible system so you can send data packets to any user that's currently in the room. for subscription, you might need to build something higher level in order to make it work here. Re: access perms, we allow you to see other participants' permissions in the same room. We do not support P2P. That's really a decision to keep our sanity. Otherwise it'll balloon the amount of complexities in the system significantly. Re: RTSP bridging, it'd be pretty straight forward to implement with our Go SDK. You can read the RTSP into RTP packets and forward them to livekit

Hi @dry-elephant-14928 thanks for your answers. Let me try to respond in order to make some of my requirements more clear. > re: data channel, we expose a pretty flexible system so you can send data packets to any user that's currently in the room. for subscription, you might need to build something higher level in order to make it work here. OK, that reads to me as if it would not be possible to publish a data channel only? Or would that be done by simply not adding any audio/video track? > Re: access perms, we allow you to see other participants' permissions in the same room. I was definitely not specific enough. I think I meanwhile have a little idea of participant data and their propagation in LK. In my systems(s) I'm having a central (server-side) REDIS database too, which holds room-"globals" per room, like what codec is to be preferred, if audio is supported at all, if P2P is supported, the maximum video bitrate and resolution. For some of those I could imagine to get rid off, that's for this, some are really historical. Those room-"globals" (I call it roomConfig) are handed out to each participant, once it enters the room as part of the JOIN response. And those are updated to all, once an administrator decides it needs to be changed. The change is an administrator's task, no participant can decide about it. Then this roomConfig holds some objects, which are not hand out to participants, but are used by the server-side code (e.g. credentials for RTSP re-publishing and more) to be used, once video is to be re-published server-side to an RTSP server (I will add more information on this later) This auto-config element is really kind of required, since we have a lot of clients, which are not operated by human during usage (like Raspberry PIs, Android libraries, Jetson Nano etc). Would you think, I could use any of your mechanisms, to picture this? To have an administrable object per room, which is made known to all participants, once they join, and which could also have some elements hidden to server-side processing only? I would rather use what is already there instead of messing up the server-side code, the more that I'm not too experienced with GOLANG at the moment... > We do not support P2P. That's really a decision to keep our sanity. Otherwise it'll balloon the amount of complexities in the system significantly. Full understanding for this. I was not seeking for this either. An SFU is an SFU is an SFU 😀 I was more looking for some custom protocol buffer message, which could be fired by any participant to any other participant in the room, and which could be loaded with the required messages to be exchanged for P2P: SDP offer and answer and ICE candidates. The rest would be my turn. Even though P2P sounds old school, for some of our customers is the security aspect (to not have a man-in-the-middle for the media) deciding. So I have to support P2P even in an LK environment. But if I can't use your server for the signaling I would have to setup yet another signaling server aside, which I would like to prevent (but would be doable, of course, if not possible). > Re: RTSP bridging, it'd be pretty straight forward to implement with our Go SDK. You can read the RTSP into RTP packets and forward them to livekit OK, that was a bit confusing from my side, sorry for this. In fact, it is the other way around. We have customers, who are fine to run VCS based on RTSP feeds. They don't want to mess with WebRTC and WebRTC clients, they are just fine to have RTSP feeds to consume. We are satisfying that by having a way to re-publish video streams server-side as RTP feeds to an RTSP server on the same server instance (more specifically this is the great Mediamtx server (https://github.com/bluenviron/mediamtx), which I love). This server does the conversion for us to primarily RTSP. But even HLS or RTMP would be doable). It then provides a previously published WebRTC audio/video as RTSP, even joined. Meanwhile see this as an advantage, because you are having a whole bunch of additional clients written for another world to be used with your WebRTC publishers (e.g. ffmpeg/ffplay, VLC, and and and) With Kurento and Mediasoup I was doing the conversion server-side for a given RTP stream using FFMPEG. Basically I acted as a customer/subscriber and negotiated the RTP for FFMPEG via internal UDP ports and a dynamically created SDP file. I am able to combine audio and video streams to either MKV or MP4, but also to re-stream audio and video separately. I was seeking for similar functionality on LK. For the recording I'm using a similar path with Kurento and Mediasoup. For server-side recording I was doing the same with FFMPEG spawns again and in order to save me from the burden of having to mess with recording files I was offering the chunks to anyone interested via HTTP POST push. That works great and the load to deal with the recordings is in other hands... And finally: I forgot to mention, that I was also looking for a way to push an "appData" object from a a publisher to a subscriber via LK for a particular audio/video/data publication. This is 100 similar to the Mediasoup "appData" element, which you can put in your call and which will arrive subscriber-side. We are using this to so to say label our publications, so that subscribes could look, if they are interested. Sorry for the long post. Looking forward to hear from your

@adventurous-twilight-28575 totally unrelated to your original post but thanks for sharing the mediamtx repo. That's exactly what I was looking for - something that can convert SRT ingest to RTMP which LiveKit supports at the moment (Until SRT ingest support that is, I saw there are references to it in code already). We found SRT to be more reliable on spotty cellular networks.

@few-appointment-20685 Thanks for letting me know.