Address mapping with STUN - TURN server

@ras coturn is easy to setup

Ich glaube ein STUN/TURN server bringt nix für Jitsi Meet:

XEP-2015 ist schon aktiviert, das ist ein Verzeichnis von STUN/TURN Servern https://xmpp.org/extensions/xep-0215.html

zusätzlich sind diese serevr konfiguriert

  stunServers: [
      { urls: 'stun:stun.l.google.com:19302' },
      { urls: 'stun:stun1.l.google.com:19302' },
      { urls: 'stun:stun2.l.google.com:19302' }
  ],

hilft nur bei p2p, da haben wir aber eh keine Probleme
not needed says main dev https://github.com/jitsi/jitsi-meet/issues/324#issuecomment-123425539

As jitsi-videobridge received TCP support, turn server is not needed anymore, as it was used to take the participants who has problems using UDP.

The role of a TURN server is to provide at least one path with a public IP address. Jitsi Videobridge is a server that runs (unless you have an unusual setup) on a public IP address. Use of a TURN server with Jitsi Videobridge is entirely redundant. It would only add extra hops and hence additional points of doubt and failure for your calls

Ultimately there are always going to be cases where things are not going to work. For example: if some of your users only support connecting to the web through an HTTP proxy, or do deep packet inspection and kill anything they don't legitimately recognize as HTTP, then you are not going to be able to connect.

mentioned in issue #12 (closed)

Nextcloud Talk braucht einen TURN server, also würde nicht schaden den auf dem OVH server (ohne NAT) aufzusetzen https://help.nextcloud.com/t/howto-setup-nextcloud-talk-with-turn-server/30794

Läuft auf eigenem Port 5349

TURN Server sollte auch auf 443 hören können, siehe https://community.jitsi.org/t/turn-server/15455/3?u=rasos

Mit nginx möglich ? https://github.com/coturn/coturn/issues/43

changed title from Adress mapping with STUN to Adress mapping with STUN - TURN server

All major video conference operators use port 443 for TURN: https://github.com/spreedbox/spreedbox/wiki/Use-TURN-server

How to set up coturn for port 443 https://github.com/spreedbox/spreedbox/wiki/Use-TURN-server - requires dedicated IP, maybe put it on a cheap extra VPS

But this may solve the p2p connection issues with two parties only in Jitsi Meet.

@rsc Wir brauchen für Jitsi Meet und nextcloud webRTC einen TURN Server. coturn gibt es als Debian Paket. coturn sollte auf Port 80/443 hören damit man auch User erreicht die hinter sehr restrikiven Firewalls sitzen - haben wir noch eine IP mit 80/443 am heu frei? coturn könnten wir am heu1 laufen lassen (Asterisk).

Port Mapping
listening-port 80 to 3478
tls-listening-port 443 to 5349

changed title from Adress mapping with STUN - TURN server to Address mapping with STUN - TURN server

A fairmeeting user mourned about using Google stun servers. We are using now this list in the Jitsi config:

    useStunTurn: true,

    // The STUN servers that will be used in the peer to peer connections
    stunServers: [
        { urls: 'stun:turn.osalliance.com:4478' },
   //   { urls: 'turn:fairmeeting.net:5349', credential: 'user', password: 'pass'},
  //  TO DO see issue #7 und #10, sollte evt auf port 443 laufen
    { urls: 'stun:stun.1und1.de:3478' },
    { urls: 'stun:stun.t-online.de:3478' },
    { urls: 'stun:stun.hosteurope.de:3478 ' }
    ],

We also should have a working TURN server for P2P.

turn.osalliance.com is provided by @armin.felder and has been configured in prosody:

turncredentials_secret = "verylongsecret"
turncredentials_port = 443;
turncredentials_ttl = 86400;
turncredentials = {
    { type = "stun", host = "turn.osalliance.om" },
    { type = "turn", host = "turn.osalliance.com", port = 443},
    { type = "turns", host = "turn.osalliance.com", port = 443, transport = "tcp" }
}

Setting up turn.fairkom.net on kas is pending https://git.fairkom.net/hosting/coturn/issues/1 : @rsc please route IP 178.63.167.177 (?) port 80 to heu1 port 3478 and port 443 to heu1 port 5349 and set certificate.

Doscumentation how to use stun/turn with Jitsi: https://meetrix.io/blog/webrtc/jitsi/setting-up-a-turn-server-for-jitsi-meet.html

turn.osalliance.com is only available for port 3478, deprecated

turn.fairmeeting.net throws a TLS error, see coturn issue 113 with that version

so use

turn.fairkom.net see https://git.fairkom.net/hosting/coturn/-/wikis/home

closed

reopened

TURN server is not used with new jvb2 anymore in ICE trials.

Maybe we need to redirect from 443 from each jvb. So adding nginx on bridge2 with adapted 60-jitsi-meet.conf:

# this is an adapted jitsi-meet nginx module configuration for aditional videobridges
# this forward all http traffic to the nginx virtual host port
# and the rest to the turn server
# RAS 2020-04-28

stream {
    upstream web {
#        server 127.0.0.1:4444;
         server 127.0.0.1:80;
    }
    upstream turn {
#        server 127.0.0.1:4445;
         server 144.76.116.175:443;
    }
    # since 1.13.10
    map $ssl_preread_alpn_protocols $upstream {
        ~\bh2\b         web;
        ~\bhttp/1\.     web;
        default         turn;
    }

    server {
        listen 443;
        listen [::]:443;

        # since 1.11.5
        ssl_preread on;
        proxy_pass $upstream;

        # Increase buffer to serve video
        proxy_buffer_size 10m;
    }
}

Results on bridge2: no difference to use TURN server.

Re-installed turn.fairmeeting.net see fairteaching#2 (comment 22604)

TURN works now for BBB and for fresh jitsi install (even from guest WLAN).

mentioned in issue #70 (closed)

coTURN server seems not to work anymore since an upgrade from coturn:amd64 4.5.1.1-1.1 to 4.5.1.1-1.1+deb10u1

downgrading did not make a difference in the logs

another sample for lua config in prosody:

turncredentials = {
   { type = "stun", host = "stun:########.com" },
   { type = "turn", host = "turn:########.com", port = 3478, transport = "udp" },
   { type = "turn", host = "turn:########.com", port = 80, transport = "udp" },
   { type = "turn", host = "turn:########.com", port = 3478, transport = "tcp" },
   { type = "turn", host = "turn:########.com", port = 80, transport = "tcp" },
   { type = "turn", host = "turns:########.com", port = 443, transport = "tcp" },
   { type = "turn", host = "turns:########.com", port = 5349, transport = "tcp" }
}

Doesn't it start at all? I had that issue after latest debian upgrade. My fix was to add

AmbientCapabilities=CAP_NET_BIND_SERVICE

into section [Service] of /lib/systemd/system/coturn.service

then called systemctl daemon-reload (as root) and restart coturn.service: systemctl restart coturn.service

BTW: It's always a good idea to look into the logs and put what you find into the issue. In my case I had a log-entry that coturn could not bind to a port. Googling for the error message found

https://github.com/coturn/coturn/issues/421

Let us know if that was the issue.

Ralf

The only suspicious entries in log we see for the turn.fairmeeting.net server are some:

625794: session 000000000000006987: TCP socket error: Connection reset by peer 192.35.169.48:19036

So nothing that would explain why Jitsi Meet is not using this TURN server anymore. Log file is nearly empty since the coturn upgrade.

Thanks for the hint, applied the AmbientCapabilities=CAP_NET_BIND_SERVICE - still no TURN connection is established through restricted guest WLAN. Some more research needed.

Checking TURN functionality on ICE test page was successful with turn.fairmeeting.net. Log verbose mode shows connections.

It seems that WLAN guest mode blocks any UDP media. Added in prosody to promote also TURN with TCP.

;; From that check, you should get at least one Server-Reflexive Candidate
;; (type "srflx") AND one Relay Candidate (type "relay").

Address mapping with STUN - TURN server

Designs

Child items 0

Activity