This message was deleted.

Hey @purple-magazine-67414, which systems are you looking to integrate with? WHEP could be interesting but would love to understand the use case better

Specifically we are working on two different systems that share this need: Integrating with an external MCU, and the other one is about integrating CV/AR real time system. In both cases we need to take real time video from WebRTC with very low latency (HLS not an option), we also need to avoid transcoding that would make scalability real hard to achieve.. In fact we are doing some trials using RTMP with relatively good results, but for a production system scalability figures are far from our target

Saul, that's helpful context! The CV/AR system takes RTMP and WHEP? Is that also true for the external MCU? Some customers have had success using our Python SDK to fetch the real-time stream to run CV classification/etc on it. What concurrent scale are you targeting?

No, I meant the sip / livekit integration, what would be left for PoC scope is the BFCPEndpoint integration. That we would be doing right after that. I mean, BFCPEndpoint is implemented and unit tests are ok, and integration with sip gateway (webrtc screen sharing) is what would be pending. We are putting all our efforts to provide you with results of PoC as soon as possible even if we had to change the integration with livekit, as we informed you last week

Hey Saul, sorry I'm not following. My question was which system that you would like to use WHEP with? Is SIP another system you are looking to integrate with?

Sorry @dry-elephant-14928 I was travelling and couldn't find time to answer your question. In fact, as you correctly guessed the MCU case is intended to serve a SIP integration with legacy cisco and tandberg equipment, and also to a different project that aims to provide video communication features to 112 services, in the end is also a SIP integration. We already have the SIP integration developed and working good, and in fact w have used WHIP to ingress SIP media to LiveKit and up to now we are using RTMP to get media from LiveKit and send it to the SIP network. The problem with using RTMP, at least what we have seen is that latency is a little bigger than expected (although near to the acceptance threshold), but the main problem is transcoding in LiveKit server. On a typical MCU we are expecting to have between 10-15 WebRTC participants plus 2-3 SIP ones. That would mean 10-15 video transcoding processes for a single MCU, and we expect a growing number of concurent sessions, so we would need to lower CPU requirements to enhance scalabiity (and better fit the costs). WHEP would be a good solution. But as we also saw on your sources that you are using gstreamer on the egress module. It would also be a good approach to have the ability to define our own egress gstreamer pipelines. In fact for our second use case (AR/CV integration) we already have a media ingestion module in gstreamer and python, so for us integration would be pretty easy wiht the second approach (defining our own gstreamer pipelines). I hope you can consider our needs in your roadmap, I am pretty sure that it could be also useful to many other users