I already consumed quite a lot of documentation (see links at the end).
- establish a udp p2p meeting with end2end-encryption using jitsi meeting
- are the assumptions made below about end2end-encryption and turnserver/videoBridge correct?
- Does the turnserver need any firewall rules to give access from outside for jitsi/prosody?
(so this is a jitsi and not a turnserver question, therefore it is not in the coturn-forum)
- did I miss something, e.g. could this work?
- At least one peer is placed behind a tcp-only/NAT firewall/proxy
- due to sometimes very poor tcp performance (lot of packet losses) udp needs to be used
- the jitsi meeting server (+prosody +jvb) is in a third place, operated by a third party, but config requests can be made
If I understood everything, then
- jitsi VideoBridge will break end-2-end encryption and for that can’t be used here
- turnserver does not break end-2-end encryption
- using coturn-Turnserver in the environment of peer A with udp keyhole punching to „open“ Firewalls from „inside“
- this configuration will only work if both Peers can use common codecs for Video/Audio
- this configuration will not work if more than 2 peers are in the meeting
Signaling path – all communications can use tcp:
Peer A <---> Proxy/FW/NAT <-I-> nginx/jitsi/prosody/STUN <-I-> Proxy/FW/NAT <---> Peer B <-I-> is standing for Internet here nginx/jitsi/prosody/STUN are behind firewalls not mentioned here
Video-/Audio-path – all communications use udp:
Peer A <---> FW <---> Turnserver <---> FW/NAT <-I-> FW/NAT <---> Peer B
Due to my opinion it should work this way:
Peer A communicates with his „local“ turnserver, which provides peer A with the information about his external NAT-address. This can be checked using trickleICE. Peer A should show a candidate of type udp relay with the external ip of the turnserver. udp connections between peer A and his “local” turnserver are opened from inside by peer A.
Peer A informs the prosody signaling server about his relay candidate, which transports this information to peer B.
Peer B contacts the STUN to get his own srflx-address and communicates this via prosody signaling server to Peer A, which informs „his“ turn-relay about the srflx-candidate of Peer B. As the turnserver is not reachable from the internet at this moment, peer B won’t provide a relay candidate.
peer A tries to reach the srflx-address of peer B using udp, which will be blocked by the firewall
the turnserver tries to reach the srflx-address of Peer b using udp, thus opening the FW udp ports (keyhole punching).
Peer B tries to reach via udp the relay candidate of peer A, thus opening the udp ports at his local FW. After the turnserver has opened the firewall ports on his side, peer B can connect to the turnserver, using it as relay to communicate with peer A.
now the Video-/Audio-communication should be established
Conclusion: I assume the turnserver doesn’t need a direct communication with jitsi/prosody as it is designed to communicate with the „inside“ peer for signaling and with the „external“ peer using keyhole punching for the udp video/audio-sessions, so no firewall rules are needed to open access from the internet to this turnserver.
iceServer-configuration includes a STUN at the jitsi-site to get srflx-address for peer B and TURN for the local site of peer A, nothing else needed.
Remark: If peer B is also behind an tcp-only/NAT-FW, than a second turnserver is needed at his location
Remark: all this is theorie, knowing that theorie not always reflects real life…
Documentation used up to now:
Getting Started | WebRTC
[Build the backend services needed for a WebRTC app: STUN, TURN, and signaling - HTML5 Rocks]
Build the backend services needed for a WebRTC app: STUN, TURN, and signaling - HTML5 Rocks)
rfc4787 (ietf.org) udp NAT