The data going over TURN is always encrypted in WebRTC, so relays can never see what you send (at least in all normal implementations).
The handshake can be sent out-of-bound like you say, but if you are not at the same physical place or have some pre-trusted way to transmit them you always need to trust something.
Even if you send it over something that is previously e2e-encrypted like signal or keybase you always need to trust that channel, so unless you actually are at the same physical place to do the handshake over a non-remote channel or have setup the channel earlier I don't think there is a way to do it "truly securely". The same is true for basically all e2e-encrypted systems that don't have a way to establish an out of bounds channel of trust (like for example the web PKI structure or the debian web of trust).
If you were to use existing web PKI (every participant having their own domain) and require all participants to encrypt with their DV/OV/EV validated keys that might work, but that also seems like a lot of work and cost for messaging and sending files.
Also, I'm not sure what threat model you are mitigating by encrypting the payload on an already e2e-encrypted channel since you load third party JS without SRI, don't have a CSP and don't have HSTS. Basically there are a few steps I'd take before worrying about having a minimal server forwarding the handshake. This seems like you have not considered what the threat model for your service actually is.
I might not just understand the cryptography here, but how does that protect against the server or a third party with access to the handshake to act as a relaying party (basically doing a MITM attack)?
Does it actually not need to trust the server or have any preexisting trust in the other party?
