What this means is that the packets are encrypted between you and the video bridge and the packets travel unencrypted within the videobridge infrastructure, but at no point does the outside world see the unencrypted stream. Talking to the Jitsi video bridge is just a regular WebRTC session as far as clients are concerned (so any DTLS encryption WebRTC has, the Jitsi call has), I know this because before they had a decent SDK I had to manually wedge my WebRTC calls into it.
If you're looking to add e2ee to your project, you're pretty much left to choose between Olm and Signal Protocol, which are quite similar, but libsignal is GPLv3 while libolm is Apache 2.0.
I've used Olm more intensively over the last two years. While it works, it's great, when it randomly wedges a session for no apparent reason you feel like throwing it out the window.
edit: it looks like you can find info in the RTCSessionDescription.sdp property. The remoteDescription and localDescription should each have key fingerprints in lines with "a=fingerprint:..."
I believe it is correct to say, that WebRTC is end-to-end encrypted. What you are referring to is, if you can trust to have a direct connection to the other participant and that you can make sure she is the person she pretends to be. This layer is indeed missing and will be added [2]
I would very much appreciate your help on the project to eliminate those concerns.
[1] https://jitsi.org/security/
[2] https://github.com/holtwick/briefing/issues/1