Janus recordings overcoming network drops

General
1

If a Janus-based webrtc application makes recordings and a peer has even a momentary network issue, Janus fails with the recording (we get empty 8 byte data.mjr files).

Network issues can happen all the time- there must be an easy way to overcome this.

Can someone please advise on how to work around this?

Is this just a matter of enhancing one of the janus.jcfg settings…

  • or is there more kind of work involved?
  • perhaps overriding/overwriting the bad packets (and ensuring that janus does not freak out during that moment) andfilling them in with black?

media: {
#ipv6 = true
#min_nack_queue = 500
rtp_port_range = “40000-65535”
#dtls_mtu = 1200
#no_media_timer = 1
slowlink_threshold = 4
twcc_period = 100
#dtls_timeout = 500
}

2

If you get empty files, that momentary network issue caused the PeerConnection establishment to fail entirely. Momentary drops on regular PCs simply results in some packets missing from the MJR file (unless retransmitted).

3

Thanks. In order to retain a continuous recording these drops, is there a way to overcome the PeerConnection failure?

I would think that this happens often…

While ICE can overcome this, how do we enable Janus recordings to overcome this?

Are we supposed to have a continuation of the recording with some bad frames instead of the completely dropped/killed recording?

4

Yes. If the PC was created, packets will come in and recordings won’t be empty: occasional losses will simply not be written to the file, packets that do get to Janus will. Your case is clearly one where the PC creation failed entirely, which means that either ICE or DTLS failed when trying to establish it. You’ll need to debug the causes with something like the Admin API.

5

Thanks!

We will check out the Admin API!

Just curious-
During the “occasional losses” what does Janus do with a recording file…
Does it write black frames, repeat previous frames?

6

It doesn’t do anything. If a packet is lost and doesn’t get to Janus, Janus has nothing to write to file.

7

So in that moment, if “Janus has nothing to write to the file”, the recording fails?

It seems you are indicating that with PC (ICE/DTLS) properly functioning then during any occasional losses the recording essentially recovers. Just not clear to me what remains of the data stream for that, in other words how is Janus responding to that moment and what is written?

8

The mjr recording can be seen as a dump of incoming RTP packets.
Basically, no RTP pkt available (due to loss and missing rtx) = gap in the recording = media not working in that time frame (if FEC is not involved).
That’s it. Janus won’t use any kind of reaction or recovery mechanism on the recording.

9

Thank you Alessandro.

From your kind input and that of Lorenzo, it is clear to me know that Janus does not implement retransmission, fallback, or recovery for recording failures… and our problem seems to be “upstream” of all this in the PC.

Thanks for the great advice-- we will check Janus Admin API logs for ICE/DTLS failures and go from there…

One question if I may ask please: recordings are failing while the live Janus broadcast video looks perfect, does that possibly point to anything else?

10

We do support retransmissions. If a packet is retransmitted, it will end up in recordings. Browsers only do retransmissions for video, though, and not for audio.

11

I’d say first of all make sure you’re using an up-to-date version of Janus and its dependencies. The “8 bytes when empty” thing makes me think you may be using an older one, as the size should be larger than that even when recordings are empty (we now save a JSON metadata object as part of the header, assuming at least one RTP packet is recorded).

I also see you talk of a data.mjr file, though: are we still talking of audio/video recordings, or are those datachannel recordings? In that case, if the user never sends a data channel message, then empty recordings are to be expected.