It looks turn server is not working in p2p.stunServers

Hi,

I verified the “One way to configure TURN support in meet with a static configuration.” mentioned in https://github.com/jitsi/jitsi-meet/blob/master/doc/turn.md, and, found that this way is not working.

The steps of this verification are,

  1. setup a coturn server at WAN (either with no-auth or with sqlitedb)
  2. setup a jitsi meet server at WAN by quick install, using config.js as,
    p2p.enabled: true
    p2p.stunServers: [ { urls: ‘PROT:turn1.AA.BB.CC’, credential: ‘XXX’, password: ‘YYY’ } ]
  3. In the same LAN, start 2 chrome browsers at two different PC, to join the same chatroom at the jitsi meet server.

And, the results are,

  • if the PROT used in p2p.stunServers is ‘stun’, the coturn server will be queried, and there will be a p2p connection between the 2 chrome browsers.
  • if the PROT used in p2p.stunServers is ‘turn’, the coturn server will never be queried, and there will be a jvb-relay connection between the 2 chrome browsers.

The above steps are repeated a few time. It looks that jitsi meet server is designed never accept turn server declared in p2p.stunServers.

I understand, to declare turn server in config.js is not secure, however, it might be a quick method to do quick internal testing. I wonder there are something wrong in the verfication steps to give this result. Appreciate any advice, Thanks !

1 Like

In order two participants to establish p2p connection they need stun server to find their addresses and ports, and if possible they will connect directly, then if not they will try to use a turn server if there is one configured, and if all fails it will fallback to jvb connection.

In order to test the turn server in p2p mode, have 2 computers in the same network for testing and on one of them using some firewall drop all communication between the two computers and as they cannot communicate the participants will use the turn server to communicate.