WebRTC how to

Why STUN/TURN?

A STUN (Session Traversal Utilities for NAT) server will allow our two end-nodes to know what their public IP is, as we most often sit behind a router in a LAN with private IP addresses. It is only used for that “getting to know each other” phase used to gather all informations about how (if proven possible) establishing our peer-to-peer WebRTC communication.

A TURN (Traversal Using Relay NAT) server is a relay server used when peer-to-peer connection cannot be established. In that case your only option is to use an external server as a relay. Symmetrical NAT, encountered more often in corporate networks, is typically the kind of NAT for which a TURN server will be used as a workaround to establish communication.

Public STUN/TURN Servers

stun.stunprotocol.org

(STUN only) is used by default in JSXC. Is known to be prone to DDoS attacks.

Warning

For Russia and parts of Ukraine, this server resolves to 127.0.0.1 (probably as a result of anti-DDoS actions taken by server maintainers). If you experience problems with WebRTC connectivity in JSXC, first of all check the STUN server availability.

URL: stun:stun.stunprotocol.org

Google STUN server

(STUN only)

URL: stun:stun.l.google.com:19302

numb.viagenie.ca

(STUN/TURN) is a public STUN/TURN server. Requires registration.

Warning

This server is known not to work with Firefox (fails to collect srflx and relay entries).

URL: turn:numb.viagenie.ca

Private STUN/TURN Server

Install and configure coturn

Below commands are for Debian, adjust to you distribution’s package manager. We need openssl version 1.0.2 minimum to support DTLS (Datagram TLS). I used the testing repo to install recent versions of both openssl and coturn:

apt install openssl/stretch coturn/stretch

You should get validated checks regarding security protocols supported when restarting coturn:

0: TLS supported
0: DTLS supported
0: DTLS 1.2 supported
0: TURN/STUN ALPN supported
0: Third-party authorization (oAuth) supported
0: GCM (AEAD) supported
0: OpenSSL compile-time version: OpenSSL 1.0.2j  26 Sep 2016 (0x100020af)

Now for the configuration (in /etc/turnserver.conf), a minimum working conf dims down to:

listening-port=3478
tls-listening-port=5349
alt-listening-port=3479
alt-tls-listening-port=5350
listening-ip=PUB.IP.NUM.1
listening-ip=PUB.IP.NUM.2
relay-ip=PUB.IP.NUM.1
min-port=49152
max-port=65535
verbose
fingerprint
use-auth-secret
static-auth-secret
userdb=/var/lib/turn/turndb
realm=example.com
cert=/etc/ssl/certs/coturn_ca.crt
pkey=/etc/ssl/private/coturn.key
dh-file=/etc/turn/dhparam.pem
no-stdout-log
log-file=/var/log/turn/turn.log

no-sslv3
no-tlsv1

This is set up to enable STUN features as well as TURN features. The TLS key/certs have to be fully functional, as TLS is a requirement and not an option (works perfectly fine with Letsencrypt certificate). You need 2 public IPs for STUN to do its magic.

coturn authentication

For TURN, because it handles the whole stream, we want it to only accept relaying authenticated nodes. To do that, you need to create at least a user account and a shared secret. They both will be used for ephemeral credential validation. In your terminal, generate an account and declare your shared secret via turnadmin command:

turnadmin -a --db /var/lib/turn/turndb -u username -r example.com -p XXXXXX
turnadmin --db /var/lib/turn/turndb -r example.com --set-secret=XXXXXXXXXXXX

Note

from what I gathered, the user password is not used for ephemeral credentials, only for long-term credentials, which are not secure.

Configure STUN/TURN server in JSXC

Static

You can pass your STUN/TURN configuration directly to JSXC as init option with the key RTCPeerConfig.iceServers using the format described in the W3C WebRTC working draft:

RTCPeerConfig: {
    /** ICE servers like defined in http://www.w3.org/TR/webrtc/#idl-def-RTCIceServer */
    iceServers: [{
        urls: ['stun:stun.domain1.org', 'stun:stun.domain2.org']
    }, {
        urls: 'turn:turn.domain3.org',
        username: 'user',
        credential: 'pass'
    }]
}

Dynamic

If you like to generate STUN/TURN parameters on the fly, just pass RTCPeerConfig.url as init option to JSXC. The endpoint has to respond with a JSON encoded representation of RTCPeerConfig:

RTCPeerConfig: {
    url: '/getWebRTCConfig.php',

    /** If true, jsxc send cookies when requesting RTCPeerConfig from the url above */
    withCredentials: false,
}

Resources

WebRTC Troubleshooter

tests all your WebRTC parameter, like Camera, Network or Connectivity.

Trickle ICE

can be used to check general STUN/TURN server availability and functioning.

NAT-Analyzer

is a tool to check your NAT type (full cone, symmetric etc.) Requires Java.