I’m a bit late to reply to you but it’s for a good reason: when you posted this I did not know. I still don’t but I’m a bit less sure about my ignorance.
I have taken a look because I’m curious but it was a bit difficult to track. I think it’s in jitsi-media-transform, file src/main/kotlin/org/jitsi/nlj/stats/EndpointConnectionStats.kt, line circa 150-170. Jitsi-media-transform is one of those libraries where Jitsi videobridge developers are putting ‘common functions’, its code is included in the bridge.
I think that RTT is related to TCC (Transport-Wide Congestion control: don’t ask me what is the exact meaning of ‘Wide’ I absolutely have no idea).
My understanding of TCC is that periodically the sender (aka JVB) sends a special packet summarizing all the normal data packets that were sent since previous TCC packet. The receiver then searches in his memory what has happened to these packets and sends back a reply giving for each of these packets a concise information along the lines of ‘not received’, ‘received normally’, ‘too late’ (or too early but it’s probably not a common occurrence).
Now this TCC packet is one of the few packets sent that needs a reply and it’s about these packets that Jvb calculate a RTT (Round Trip Time). It is my understanding that this round trip time is used to limit the frequency of TCC packets (since these are ping pong packets their use must be limited else it could actually harm the real data use in case of loaded networks).
You can see in the code that the limit is 7 seconds. What could be the reason a client should take the full enormous time of 7 seconds to reply to a single packet ? IMO one of the principal possibilities is that the client is overwhelmed and has too much to do. In my tests I have seen that even moderate activity on a PC can produce a significant jump in RTT (not that much though; certainly not 7 seconds).
Maybe some complicated network configuration (across the world) could account for one or 2 seconds also.
What could you monitor ? IMO using the logs is awful for that, but maybe you could figure out some way to find if some clients exhibit this behavior more than others: in this case the ‘overwhelmed client’ could be the preferred hypothesis.
If all clients are showing this problem at some point of time, but not normally, it could be a network problem. I hope that you are monitoring your JVB(s) so the possibility of an overwhelmed JVB is not thinkable.
If you are using Octo, the general network problem is much more likely of course.
Well, that’s all I can say and maybe some part is wrong, I don’t belong to the ’ highly qualified and supremely knowledgeable with all things Jitsi’ people posting in this forum.
You can find the RFC here and the code is here, hope that you will gather knowledge from these readings.