Jump to: navigation, search

TURN Server Installation and Configuration

Configure your Existing TURN Server (Non-Genesys)

If you already have a TURN server deployed in your network and prefer to use it instead of the Genesys Collaboration TURN Server, then do the following:

Install and Configure Genesys Collaboration TURN Server

Host Requirement

  • RHEL/CentOS 6.x.
  • At least two vCPUs, 4GB Memory. SSD may be used, but is not mandatory.
  • The most important factor is the networking performance. Make sure that your network has:
    • High packet per second (PPS) performance
    • Low network jitter (<= 30ms)
    • Low latencies (<= 150ms)

For example, if you are deploying the TURN server in an AWS instance, then Enhanced Networking is only available on instances launched with HVM AMIs. Preferably, use C3/C4/R3 instances. For details on AWS EC2 instance types, check here.

Port Requirement

TURN server port requirements are described in the Port Usage section.

The Collaboration TURN Server IP for TURN server is available with this release and must be installed on a separate server. If you want to install the TURN server in the same machine as the Application Server, make sure there is no port conflict.

You must have root access to install the TURN server. To configure the server:

  1. If you are using a 64-bit OS, the /etc/yum.conf file must include multilib_policy=all.
  2. Ensure Selinux is disabled by editing the /etc/sysconfig/selinux file, and make sure that this line is set to disabled:
    SELINUX=disabled
  3. Turn off the firewall by running:
    sudo chkconfig iptables off

    Note: The firewall can be turned on again and configured as per your requirements at a later date.

  4. Reboot the server by running:
    sudo reboot
  5. After the server has rebooted, log in and verify Selinux is disabled using the command:
    sudo getenforce

    This returns Disabled.

  6. Create the directory /opt/zenon by running:
    sudo mkdir -p /opt/zenon
  7. Place the files from your Collaboration TURN Server IP to /opt/zenon.
  8. After unpacking, you will see the directories: sh, trn, trnssl, extras and files: root_cron and zenon_zs.
  9. Make sure that the .sh and some other files have execute permission:
            cd /opt/zenon
            sudo chmod -R +x *.sh
            sudo chmod +x zenon_zs
            sudo chmod +x trn/bin/turnserver
            sudo chmod +x trnssl/bin/turnserver
  10. Run the extras/install.sh file to install the pre-requisite libraries:
            cd extras
            sudo install.sh
  11. Copy the contents of root_cron. Then run:
    sudo crontab -e
  12. Paste the contents of root_cron and save.
  13. The zenon_zs file is the startup script used by the server to start the TURN services after reboot. Copy this file to the folder /etc/init.d, and then make the file executable.
  14. Create a link to it in /etc/rc3.d as follows:
    cd /etc/rc3.d
    sudo ln -s /etc/init.d/zenon_zs S99zenonzsstart

    Note: This presumes that the runlevel of the server is 3. Typing sudo runlevel at the command line will confirm this. If 5 is returned, create the link in /etc/rc5.d

  15. To configure the TURN services for UDP on port 14049:
    cd /opt/zenon/trn
    sudo ./configure_trn.sh yourdomain.com X.X.X.X

    Where X.X.X.X is the IP of the TURN server interface it will be listening on (typically eth0).

  16. To configure the TURN service for SSL on port 443:
    cd /opt/zenon/trnssl
    sudo ./configure_trnssl.sh yourdomain.com X.X.X.X
  17. An MCU password is required for the TURN server to communicate with it, and is stored in these files:
    • /opt/zenon/trn/bin/turnuserdb.conf
    • /opt/zenon/trnssl/bin/turnuserdb.conf
  18. The line starting with mcu: must be noted (or edited in both files if a change is required). The same password as configured in TURN Configuration in Application Server Settings should also be set here.
      Note: We are currently using the long-term credentials approach for TURN server authentication. With this approach, the client-side JavaScript has access to the TURN server credentials. There is a short-lived credentials approach using TURN REST API to provide more security; currently, this is not implemented in GVG.
  19. Finally, reboot the server by typing sudo reboot, and TURN services should be running when the server is brought back up. This can be confirmed using the command sudo ps -elf | grep trn that returns output like this (example output):
    root     25313  0.0  0.0 106480  1676 ?        S    Jul04 107:29 /bin/sh /opt/zenon/sh/trnserver.sh
    root     25351  0.0  0.0 163860 16052 ?        Ssl  Jul04  32:32 /opt/zenon/trnssl/bin/turnserver -v -o -X 72.28.111.195 -a -b /opt/zenon/trnssl/bin/turnuserdb.conf -f -r mac1.saypage.com
    root     26443  0.3  0.0 304676  9264 ?        Ssl  Jul04 579:24 /opt/zenon/trn/bin/turnserver -v -o -X 72.28.111.195 --no-tls -a -b /opt/zenon/trn/bin/turnuserdb.conf -f -r mac1.saypage.com

Configure TURN Behind-NAT Settings

Note: You only need to perform this step if your TURN server is behind NAT.

  1. When the TURN server is behind NAT, you must modify the following files:
    • /opt/zenon/trn/bin/run.sh
    • /opt/zenon/trnssl/bin/run.sh
  2. Before modification, the first run.sh file will look like this:
    /opt/zenon/trn/bin/turnserver  -v -o -X <local_ip> --no-tls -a -b /opt/zenon/trn/bin/turnuserdb.conf -f -r <public_realm>
  3. After NAT modification, the file looks like this:
    /opt/zenon/trn/bin/turnserver -o -X <public_ip>/<local_ip>  --no-tls -a -b /opt/zenon/trn/bin/turnuserdb.conf -f -r <public_realm>
  4. Before modification, the second run.sh file for TURN via SSL looks like this:
    /opt/zenon/trnssl/bin/turnserver -v -o -X <local_ip>  -a -b /opt/zenon/trnssl/bin/turnuserdb.conf -f -r <public_realm>
  5. After NAT modification, the file looks like this:
    /opt/zenon/trnssl/bin/turnserver -v -o -X <public_ip/local_ip>  -a -b /opt/zenon/trnssl/bin/turnuserdb.conf -f -r <public_realm>

Verifying your TURN Server

To verify whether your TURN server is running properly and is accessible, go to the following demo page:

http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

This page tests the trickle ICE functionality in a WebRTC implementation. It creates a PeerConnection with the specified STUN/TURN servers, and then starts candidate gathering for a session with a single audio stream. As candidates are gathered, they are displayed in a text box, along with an indication when candidate gathering is complete.

Select and remove the default STUN server that is populated in this page, and then add your TURN server(s) instead. For example, if you have installed the Genesys TURN server in turn.example.net and set password as genesys for mcu user, add both:

  • turn:turn.example.net:14049 (and user/password as mcu/genesys)
  • turn:turn.example.net:443?transport=tcp (and user/password as mcu/genesys)

Then press Gather candidates and specifically check for relay candidates in the result (see example below). If no relay candidates are generated, either your TURN server is not running properly or is not accessible from your network.

GVTURNServerRelayCand.PNG

Also, the type of candidates released to the application can be controlled via the IceTransports constraint.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on April 26, 2016, at 15:16.