We have an application where we’d like to have fine control (ideally on a packet-by-packet basis) over whether and when packets actually get transmitted between clients. For example, we’d like to record packets into a file, and hold off on transmitting the packet until we are sure that this file-write will be successful. (It is more important to us that every packet be recorded than that more packets get forwarded.) As another example, we’d like to have a single piece of mutable state, and ensure that no packets get transmitted whenever that state is not “live”. (If our packet-by-packet inspector always checks this state before forwarding, we get a simple guarantee about correlation between this state variable and the application behavior.)
Our current approach is to use a DirectTransport that sits between two WebRTCTransports. Client A produces, making producerA
. We have a DirectTransport make middleConsumer
that consumers producerA
, a middleProducer
that is manually managed, then consumerB
that consumes the middleProducer
. We then listen for packets on middleConsumer
and manually sendRtp()
to the middleProducer
once we are ready to forward them.
This works in a lot of cases, except when producerA
is simulcast. In that case, consumerB
becomes unable to switch simulcast layers. This is because switching layers requires RTCP Sender Reports for synchronization, and the Sender Reports from producerA
are lost in the above process (they are received by middleConsumer
and then vanish, and there is no exposed way to listen for them from JavaScript).
What do you think the best way would be to accomplish what we want? So far our two candidate solutions are:
- Modify mediasoup so that Consumers and Producers on DirectTransports expose Sender Reports and Receiver Reports for forwarding, e.g. through new events
on("senderReport")
andon("receiverReport")
. (If we did this we’d presumably also have to translate SSRCs when forwarding the reports). - Stop using DirectTransport for this, and instead reverse-proxy all our WebRTC traffic and do our intervention within that reverse proxy, at the level of UDP packets (instead of RTC packets).
Is there a better way to do this that’s already built into mediasoup? Or if not, which of these solutions seems cleaner?