{"id":6737,"date":"2018-01-29T14:53:15","date_gmt":"2018-01-29T22:53:15","guid":{"rendered":"\/developerblog\/?p=6737"},"modified":"2020-03-20T09:12:58","modified_gmt":"2020-03-20T16:12:58","slug":"orchestrating-turn-servers-cloud-deployment","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/ise\/orchestrating-turn-servers-cloud-deployment\/","title":{"rendered":"Orchestrating TURN Servers for Cloud Deployment"},"content":{"rendered":"

Background<\/h2>\n

We recently collaborated with Aveva<\/a>,\u00a0an industrial design and management software company. The goal for\u00a0Aveva was to improve its remote rendering service and extend this technology to support an ever-growing list of platforms and devices including HoloLens. As a result of our collaboration, we built\u00a03DToolkit<\/a>, a\u00a0toolkit for creating powerful cloud-based 3D experiences which stream to low-powered devices that are traditionally out of reach.<\/p>\n

One of the key decisions we had to make was the video transport technology. After investigating different options,\u00a0WebRTC<\/a> emerged as the best choice for this project. WebRTC is designed to work peer-to-peer. In our case, one of the peers is a cloud server that streams video, and the other peer is a client device that might need to traverse NAT gateways<\/a> and firewalls. For these cases, WebRTC APIs use STUN servers<\/a> to get the IP address of the device, and TURN servers<\/a> to function as relay servers.\u00a0This code story will cover how we orchestrated TURN servers for cloud deployment in our work with Aveva.<\/p>\n

The Challenge<\/h2>\n

There are free STUN servers<\/a> available to use but maintaining TURN servers that relay video traffic is\u00a0resource intensive. As part of our\u00a0solution, we had to set up and maintain\u00a0our own TURN servers. The challenge was to create a simple process for deployment and to find an implementation of TURN that would satisfy the following requirements:<\/p>\n

    \n
  1. Supports STUN server functionality<\/li>\n
  2. Compliant with base TURN and STUN specs RFC 5766<\/a>, RFC 3489<\/a>, RFC 5389<\/a>, RFC 6062<\/a>.<\/li>\n
  3. Free and open source<\/li>\n
  4. Can be easily set up on the Linux platform<\/li>\n
  5. Works over both TCP and UDP protocols<\/li>\n
  6. Supports TURN authentication mechanisms such as long-term credentials and time-limited secret-based authentication<\/li>\n
  7. Uses a database to store authentication data in a central location<\/li>\n
  8. Supports protocols\u00a0TLS, DTLS with a real world certificate<\/li>\n
  9. Supports load balancing<\/li>\n<\/ol>\n

    The Solution<\/h2>\n

    After investigating different implementations of TURN servers that would\u00a0satisfy all of the above requirements we decided to use coturn<\/a>, an open source and fully spec-compliant TURN server.<\/p>\n

    Simplest TURN server<\/h3>\n

    To run the first simple version of TURN server that satisfies first 5 requirements, we deployed an Ubuntu virtual machine in Azure, added rules to open ports 3478 and 5349, connected to the machine remotely via SSH and ran the following commands:<\/p>\n

    sudo apt-get update \r\nsudo apt-get install -y dnsutils \r\nsudo apt-get install -y coturn\r\nsudo rm -rf \/var\/lib\/apt\/lists\/*<\/pre>\n
    Next, we created a file with the script listed below. It prints configuration information to \/etc\/turnserver.conf<\/span>\u00a0, such as listening, relay and external IPs and a reference to a self-signed certificate. It also adds credentials to the SQLite database that is running on the same server using the\u00a0turnadmin<\/a> command.<\/p>\n
    internalIp=\"$(ip a | grep -Eo 'inet (addr:)?([0-9]*\\.){3}[0-9]*' | grep -Eo '([0-9]*\\.){3}[0-9]*' | grep -v '127.0.0.1')\"\r\nexternalIp=\"$(dig +short myip.opendns.com @resolver1.opendns.com)\"\r\n\r\necho \"listening-port=3478\r\ntls-listening-port=5349\r\nlistening-ip=\"$internalIp\"\r\nrelay-ip=\"$internalIp\"\r\nexternal-ip=\"$externalIp\"\r\nrealm=$3\r\nserver-name=$3\r\nlt-cred-mech\r\nuserdb=\/var\/lib\/turn\/turndb\r\n# use real-valid certificate\/privatekey files\r\ncert=\/etc\/ssl\/turn_server_cert.pem\r\npkey=\/etc\/ssl\/turn_server_pkey.pem\r\n \r\nno-stdout-log\"  | tee \/etc\/turnserver.conf\r\n\r\n\r\nturnadmin -a -u $1 -p $2 -r $3\r\n\r\nturnserver<\/pre>\n
    The script requires 3 parameters (username, password, and realm) that will be sent as authentication data to the TURN server. Running the script will start the TURN server.<\/p>\n
    sudo bash deploy.sh user password123 somerealm.com<\/pre>\n
    To validate that TURN server works, we used\u00a0WebRTC Trickle ICE page<\/a>.<\/p>\n
    \"Image<\/p>\n
    Docker container with simple TURN server<\/h3>\n
    To make our server reusable and easy to deploy in any operating system and environment, we Dockerized the above scripts. This image is available in Docker Hub<\/a>.<\/p>\n
    With this setup, we can run the Docker container on any Unix VM with Docker installed:<\/p>\n
    sudo docker run -d -p 3478:3478 -p 3478:3478\/udp --restart=always zolochevska\/turn-server username password realm<\/pre>\n
    More advanced TURN server in Azure<\/h3>\n
    To be able to use a TURN server in a production environment, we needed it to satisfy the last four items in our requirements list. This situation leads to a much more complicated deployment process, as it\u00a0requires:<\/p>\n