SRTP for remote publishers in video rooms

General
1

Hello!

We use SFU cascading in our implementation to scale video rooms across several servers. The servers belong to the same private network, so publishing remotely across the servers via plain RTP makes obvious sense.

However, there is always this tiny risk of scenarios where a RTP stream being received on a set of ports is somehow reassigned to a different video room. One simple example is, say, that Janus crashes on a server, but the other Janus servers were still publishing RTP streams to it. If Janus is restarted again, and the other servers weren’t aware of this, then these ports could eventually get assigned to a different remote publisher, causing 2 different RTP streams being pushed to that port. This case, of course, should be avoided by the infrastructure using Janus, i.e, broadcast to all other Janus servers to remove remote publishers to this server before the Janus process is restarted. But it may not always be possible to capture all sorts of freak scenarios (i.e the signalling going bad, undiscovered bugs in the infrastructure code).

If remote publishers were to support SRTP, then we would at least be sure that we don’t end up forwarding a different stream, even if we mess up elsewhere.

I just wanted an opinion on whether supporting SRTP for remote publishers makes sense, or if is there some other clever trick we could consider to avoid such scenarios (for eg. identify that there are 2 different RTP streams being pushed on a port, and avoid forwarding altogether).

Thanks!
Archit

2

Regular forwarders in the VideoRoom already support SRTP. If you mean the new remote publishers feature (which internally uses forwarders), then no, those don’t support SRTP yet, and I’m not sure when we’ll add it, since it’s a bit more tricky (all RTP streams are multiplexed on the same port).

3

Thanks for your answer.

I did mean the new remote publishers feature. Was it be expensive, resource wise, to associate separate ports for each stream for a remote publisher, like we do with regular forwarders? Or was there some other obvious reason to multiplex the streams?

4

With frequent renegotiations it would have been a nightmare to update ports all the time. This allows us to act as a pseudo PeerConnection over which we can multiplex multiple RTP streams.

5

Thanks. That makes a lot of sense now. Our use case does not have any renegotiations, so we were only looking from that lens. We will see if we can use the older RTP forwarding design, or explore the feasibility of supporting SRTP streams multiplexed on the same port.