Browsed by
Category: Collaboration

How to Install Jitsi Meet on Ubuntu

How to Install Jitsi Meet on Ubuntu

PS: If you need professional assistance about installing & configuring Jitsi Meet, you can contact me via contact link.

Jitsi Meet is a very usable and simple WebRTC based open-source multi-platform video conferencing solution. It can be even cloud based solution or you can install it on your premises. In this blog post, I will explain how to install Jitsi server on your Ubuntu based linux platform.

Installing Jitsi Meet is very easy if you want to install it on Ubuntu linux platform. In this guide you can find how to install Jitsi Meet on Ubuntu by using .deb packages.

I assume that you can install Ubuntu linux and I will continue from that point.

First, let’s install base packages like sudo & ssh, so set that up first. Log in from console as root, then install the necessary packets.

apt-get install -y ssh sudo ufw apt-transport-https

Add your non-root user (mine is ferikci) to /etc/sudoers file.

 ferikci  ALL=(ALL:ALL) ALL 

Now you can continue with your user by using sudo commands.

(Optional) Enable UFW firewall and open the needed ports:

ufw allow in ssh
ufw allow in http
ufw allow in https
ufw allow in 10000/udp
ufw enable

I have to warn you that if you are connected to your linux machine via SSH, enter “ufw enable” command after entering “ufw allow in ssh” command, otherwise you may lose your current SSH connection.

If you will use your Jitsi server with a hostname, please be sure that /etc/hosts file includes your hostname: localhost jitsi.test.local

Now re-login with your non-root user via SSH for the rest of the setup.

Add the Jitsi GPG key.

wget -qO - | sudo apt-key add -

On Ubuntu systems, Jitsi requires dependencies from Ubuntu’s “universe” package repository. To do this, add the universe repos with the following command:

apt-add-repository universe

Add the Jitsi repository and update apt

sudo sh -c "echo 'deb stable/' > /etc/apt/sources.list.d/jitsi-stable.list"
sudo apt-get -y update

Install Jitsi-Meet

Now you’re ready for Jitsi server installation. Use the command below to install jitsi-meet with dependencies:

sudo apt-get -y install jitsi-meet

You will be asked your hostname but do not only write your hostname, you MUST write as FQDN, otherwise you will encounter with problems. By the way, be sure that the FQDN can be addressable with your DNS server (Or you can insert the FQDN to your host file.).

Jitsi Hostname Configuration

After that you will be asked for certificate. In this installation I will use self-signed SSL certificate, so select the first option.

Jitsi SSL Certificate Configuration Menu

The installation will be completed after a while and it will put you to the command prompt. Reboot your linux machine:

sudo reboot

Now it’s time to connect to your video conference GUI. Use https://FQDN to go to the main page of Jitsi server:


You will see a greeting page with a room name input field. Just enter a room name and click Go button.

Jitsi Meet Greeting Page

That’s it! You can add more participants with the same procedure or by using URL https://FQDN/roomname

Finally Jitsi Meet is Alive!

Running Jitsi Meet Behind a NAT

If you wish to use your Jitsi server behind a NAT, you must configure your router to forward the following ports to your Jitsi Meet server:

  • 80/TCP
  • 443/TCP
  • 10000/UDP

Next you have to add following lines to /etc/jitsi/videobridge/ file:[INTERNAL.IP.ADDRESS][PUBLIC.IP.ADDRESS]

For example, here is my configuration:
Cisco Webex Room USB Review

Cisco Webex Room USB Review

As you know in video conferencing and collaboration technologies, Cisco is the hardware and software manufacturer with the highest market share. However, as software-based solutions have emerged over the past 1-2 years, there has been an increasing demand for integrated video conferencing devices as well as audio and video transceivers. While Logitech took the lead in this market, there were many innovative products on the market (I also reviewed the most innovative Jabra Panacast in this article). Cisco will also want to take a share in this market that last January it made a serious introduction with its new product, Webex Room USB.

Cisco Webex Room USB is a device that turns any endpoint (Laptop, Desktop, SFF PC etc.) into a video collaboration center. The software you use does not even need to be Cisco, you can use this device with any collaboration platforms (eg. Microsoft Teams, S4B, Zoom, Slack, Jitsi etc.). Let’s examine the features of this device in more detail.

Cisco Webex Room USB Features

Cisco Webex Room USB is an ideal device for meeting rooms with 2-5 participants thanks to its 120 degree view camera. Basically, the device is in the form of a soundbar with embedded camera and placed on top of the screen. Apart from that, it has a remote control and a USB cable. There are also kits for display and wall mounting, a physical privacy cover for the camera, and two cables for HDMI and Ethernet connectivity. The prominent features of the device are as follows:

  • Camera Quality: Cisco Webex Room USB has a 4K UltraHD camera that can shoot video at 60 frames per second. It can automatically adjust the brightness and white balance supported by the 8MP image sensor for maximum clarity. With the artificial intelligence technology it contains, it has the feature to intelligently frame the image and a number of analytical functions for meetings so that everyone can be clearly seen by automatically detecting the meeting participants.
  • Sound Quality: There are integrated microphones and speakers on the device. Thanks to it’s automatic noise reduction feature, it can filter out distracting ambient sounds such as paper rustling and tea sugar mixing sounds. With the speaker design, it offers a more saturated sound experience, especially at low frequencies where human voice is dominant. To listen to the difference in sound with other manufacturers (Logitech), you can check out the video in this link.
  • Digital Signage Display: I think this feature is the most important feature of Cisco Webex Room USB that distinguishes it from other competitors. It can be used to turn connected PC displays into a digital signage when the device is not in use. You can use this feature for sharing corporate news, creating brand awareness, etc.
  • Content Sharing: It supports 4K content sharing as well as wireless content sharing via the web browser. In this way, you can find the opportunity to reflect your content on the screen easily.
You Can Also Use Webex Room USB As A Digital Signage Display

Apart from these, you can access more detailed technical features through the datasheet in this link.

Comparison With Other Vendors

As I said at the beginning, there are a few players in this market, especially Logitech. In the table below you can find comparison with the two most common devices:

Product /FeatureCisco Webex Room USBLogitech MeetUpPoly Studio
USB Camera, Speakers & microphoneYesYesYes
Intelligent Camera & SoundYesNoNo
Device SettingsYes (via Webex Control Hub)NoNo
Wireless content Sharing Yes (via Webex or a web browserNoNo
Digital Signage Display Yes (via Webex Control Hub) NoNo

In the video below you can see how you can connect Webex Room USB to your computer and use it as an audio and video device:

Cisco Webex Room Kit Mini USB

Cisco Webex Room USB Price

If you have a software solution or a service subscription for your video calls, you can get this device, which provides a Webex Room Kit Mini quality call experience, at a list price of $ 2,750 (of course, this is not the actual sale price). Compared to the Webex Room Kit Mini, the price of Room USB is less than half the price of Mini.

Last Words

For small businesses and organizations that want to switch to video communication, it might be a good idea to start with Cisco Webex Room USB and then turn it into a Room Kit Mini with an upgrade kit. In this way, you can both keep the initial investments very low and have a solution that will provide the highest level of video call experience.

SIP Messages & Explanations

SIP Messages & Explanations

SIP is a communication protocol that is very similar to HTTP, and the SIP messages within this protocol are very similar to HTTP messages. Just like in HTTP, SIP messages have 3-digit codes starting with the numbers 2, 3, 4, 5 and 6. Let’s examine the most common and used SIP messages before proceeding to detailed descriptions of these messages:

Most Common SIP Messages & Their Explanations

REGISTERTo register the URI listed in the To header field to a SIP server and associate it with the network address given in the Contact header field.
INVITEStarts a communication to search. The request is sent to a SIP server by a user client (eg. IP phone). When sent during a currently established communication (RE-INVITE), it changes the session (eg. put the call on hold).
ACKUsed to verify that you received a final response to an INVITE request.
BYEReports that a communication has been terminated and ends the call.
CANCELCancels all pending requests. Used to end a call that is still ringing.
UPDATEChanges the state of the session without changing the state of communication.
REFERRequests the Recipient to make a request to transfer the call.
PRACKTemporary approval. It is sent in response to a temporary response.
SUBSCRIBEStarts a subscription for reporting events from a notification.
NOTIFYUsed to notify notifications of a new event to a subscriber.
PUBLISH Used to broadcast an event on the notification server.
MESSAGESends a text message. It is used in instant messaging applications.
INFOUsed to send mid-session information that does not change session state. This method is generally used for DTMF relay.
OPTIONSQueries the capabilities of an endpoint. It is often used for NAT and keepalive.

You can also find SIP messages starting with 3-digit codes below:

SIP Messages Beginning with 1XX

These are informational responses. It reports that the request is valid and has been processed. It is used to report temporary situations such as Trying or Ringing.

  • 100 Trying : Dispatched in response to INVITE message. It may take some time to find out where the target is, so the SIP proxy sends this response.
  • 180 Ringing : Target user agent (dialed number) received INVITE and rings the phone.
  • 181 Call Is Being Forwarded : Servers can optionally send this response to indicate that a call is forwarded.
  • 182 Queued : Indicates that the destination is temporarily unavailable, so the server queues the call (on hold) until the destination is available. A server can send more than 182 responses to update the queue progress.
  • 183 Session Progress : This response is used to send additional information for a call that is currently being established.
  • 199 Early Dialog Terminated : Used by a User Agent Server to indicate that an early communication has been terminated to the upstream SIP entities.

SIP Messages Starting with 2XX

Indicates that the request was successfully completed. Indicates that a call has been made in response to an INVITE message. Indicates a recent success. The most common code is 200 OK.

  • 200 OK : Indicates that the request was successful.
  • 202 Accepted : Indicates that the request has been accepted for processing, but the transaction has not been completed.
  • 204 No Notification : Indicates that the request was successful, but no response is received.

SIP Messages Beginning with 3XX

These codes are used if call forwarding is required to complete the request. With these codes, the request will be completed on a new target. It is also used to indicate a malfunction, but also contains information about the user’s new location or alternative places that can answer the call. These are typical responses generated by IP phones when features such as Forward All Calls or Do Not Disturb are enabled on the phone.

  • 300 Multiple Options : The address indicates that the user or client listed in the message body or the Contact fields of the message has been resolved to one of several options to choose from.
  • 301 Moved Permanently : The original request indicates that the URI is no longer valid, and its new address is given in the Contact header field. The client should update the original request URI records with the new value.
  • 302 Moved Temporarily : The request should retry with the address in the Contact field. If there is an Expires field, the client can cache the result for this time.
  • 305 Use Proxy : Indicates that there is a proxy in the Contact field that must be used to reach the desired destination.
  • 380 Alternative Service : Indicates that the call has failed but there are alternatives in the message body.

SIP Messages Beginning with 4XX

It is the most crowded message code family. If the incoming request cannot be completed on the server for various reasons, it is used to indicate the error status, but it is a condition caused by the SIP Proxy that generates this message. This means that some other SIP Proxies, if any, can successfully process the request.

  • 400 Bad Request : Dispatched when the request cannot be understood due to malformed syntax.
  • 401 Unauthorized : Dispatched when user authentication is required for the request. This answer is given by UAS and SIP registrar.
  • 402 Payment Required: Dispatched when payment is required for the request. (reserved for future use)
  • 403 Forbidden : Dispatched when the server understands the request but refuses to fulfill it. It can also mean that the call was rejected by the recipient.
  • 404 Not Found : The server sends this message when the user is not in the domain specified in the Request-URI. This is also returned if the domain in the Request URI does not match any of the domains processed by the recipient of the request.
  • 405 Method Not Allowed : Dispatched when the method specified in the Request-Line is understood but not allowed for the address defined by RequestURI.
  • 406 Not Acceptable : Dispatched when there is an unacceptable status according to the Accept header information sent in the request.
  • 407 Proxy Authentication Required : Dispatched when user authentication is required for the request. This answer is given by proxies.
  • 408 Request Timeout : Dispatched when the user specified in the request cannot be found within the required time. The client can repeat the request without making changes at any time.
  • 409 Conflict : Dispatched when the user is already registered. (Deprecated due to subsequent removal from RFCs.)
  • 410 Gone: Dispatched when this once existing user is no longer available.
  • 411 Length Required : Dispatched when the server will not accept the request without a valid Content-Length. (Deprecated due to subsequent removal from RFCs.)
  • 412 Conditional Request Failed : Dispatched when the specified prerequisite is not met.
  • 413 Request Entity Too Large : Sent when the body of the request message is too large.
  • 414 Request URI Too Long : Dispatched to indicate that the server refuses to service this service if the request is longer than the server can interpret.
  • 415 Unsupported Media Type : Dispatched when the body of the request message is of an unsupported format.
  • 416 Unsupported URL Scheme : Dispatched when the Request-URI is not supported by the server.
  • 420 Bad Extension: Dispatched when an invalid SIP Protocol extension is used, when not understood by the server.
  • 421 Extension Required : Dispatched when the server needs a specific extension not listed in the Supported header.
  • 422 Session Interval Too Small : The request received is sent when it contains a Session-Expires header field with a time below the minimum timer value.
  • 423 Interval Too Brief : Dispatched when the source’s Expiration time is too short.
  • 424 Bad Location Information : Dispatched when the location content of the request is malformed or otherwise inadequate.
  • 428 Use Identity Header : Dispatched when the server configuration requires an Identity header header and this value is not provided in the request.
  • 429 Provide Referrer Identity : Dispatched when the server does not receive a valid Referred-By token on request.
  • 430 Flow Failed : Dispatched when a specific stream of a user agent fails while other streams are successful. This response is designed to be used between proxy devices and should not be seen by the end device (if it is seen by it, it should be considered as 400 Bad Request).
  • 433 Anonymity Disallowed : Indicates that the request was rejected because it is anonymous.
  • 436 Bad Identity-Info : Dispatched when the request has an Identity-Info header and the URI schema record in this header is not understood.
  • 437 Unsupported Certificate : Dispatched when the server cannot verify a certificate for the domain signing the request.
  • 438 Invalid Identity Header : Dispatched when the server has a valid certificate for the request to sign the request but cannot verify this signature.
  • 439 First Hop Lacks Outbound Support : Dispatched when the first outbound prox that the user attempts to register does not support the “outbound” feature of the RFC 5626, although the register supports it.
  • 440 Max-Breadth Exceeded : If a SIP proxy determines that a response context has insufficient Incoming Max-Breadth value to execute a desired parallel fork, and the proxy does not want to compensate by forcing it or by sending a redirect, 440 response of this proxy should send. A client receiving the 440 response may cause his request to fail to reach all possible targets.
  • 469 Bad Info Package : If a SIP UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 response, which contains a Recv-Info header field with Info Packages for which the UA is willing to receive INFO requests.
  • 470 Consent Needed : If the source of the request is not allowed to make such a request for the buyer It skinned.
  • 480 Temporarily Unavailable : This message is sent when the called number is temporarily unavailable.
  • 481 Call / Transaction Does Not Exist : Dispatched when the server receives a request that cannot match the request with any dialog box or transaction.
  • 482 Loop Detected : Dispatched when the server detects a loop.
  • 483 Too Many Hops : Dispatched when the call passes over too many hops (when the Max-Forward header reaches ‘0’).
  • 484 Address Incomplete : Dispatched if the request-URI header is missing.
  • 485 Ambigious : Dispatched if the request-URI header is uncertain.
  • 486 Busy Here : Dispatched if the called number is busy.
  • 487 Request Terminated : Dispatched when the request is terminated by BYE or CANCEL.
  • 488 Not Acceptable Here : Dispatched when Session Description or Request-URI parameters are not accepted.
  • 489 Bad Event : Dispatched when the server does not understand an event packet in the Event header.
  • 491 Request Pending : Dispatched when the server has other pending requests from the same dialog box.
  • 493 Undecipherable : Dispatched when the server cannot decrypt the MIME body in the incoming request.
  • 494 Security Agreement Required : Dispatched when the server receives a request that requires a negotiated security mechanism and the response contains a list of appropriate security mechanisms or digest authentication issues that the requester can select.

SIP Messages Starting with 5XX

Messages that are received when the server fails to fulfill a valid request, including server internal errors. Used to indicate that the PBX server encountered an internal error.

  • 500 Internal Server Error : Dispatched when the server is unable to fulfill the request due to an unexpected situation.
  • 501 Not Implemented : The server sends this message if it is not capable of fulfilling the request because it does not recognize the request method.
  • 502 Bad Gateway : The server can send this message if it behaves like a gateway or proxy and received an invalid response from a sub-server when trying to fulfill the request.
  • 503 Service Unavailable : Sends this message if the server is under maintenance or temporarily overloaded and therefore cannot process the request. With the Retry-After header, Sunuu can specify when the client can retry the request.
  • 504 Server Timeout : The server sends this message if it tried to access another server while trying to process the request and did not receive a response.
  • 505 Version Not Supported : The server sends this message if it does not support this version of the SIP protocol.
  • 513 Message Too Large : Sends this message if the length of the server request message is longer than the server can handle.
  • 555 Push Notification Service Not Supported : The server sends this message if a ‘pn provider’ does not support the push notification service defined in the SIP URI parameter.
  • 580 Precondition Failure : Sends this message when the server is inadequate or unwilling to meet some of the restrictions mentioned in the offer.

SIP Messages Beginning with 6XX

Indicates a general error, including the rejection of the call by the target. The final is used to indicate an error condition and indicate that it is of a general nature, and indicates that this request cannot be handled by any other SIP Proxy under any circumstances.

  • 600 Busy Everywhere : All possible locations are busy. Unlike the 486 response, this response indicates that the target knows that there are no alternative destinations (such as a voicemail server) that can accept the call.
  • 603 Decline : Sends this message when the destination does not want to participate in the call or knows that there are no alternative destinations (such as a voicemail server) who wants to make the call and also the destination accepts the call. A better search is specified in the Retry-After header field in the response.
  • 604 Does Not Exist Anywhere : The server sends this message if it knows that the requested user is not found anywhere.
  • 606 Not Acceptable : Indicates that the user’s agent has been successfully communicated, but some values ​​such as desired media, bandwidth, or addressing style of the session description are unacceptable.
  • 607 Unwanted : If the called party does not want this call of the calling party, this message is sent. It is likely that future calls of the calling party will be similarly rejected.
  • 608 Rejected : This message is delivered when an agent rejects the machine or process call attempt. This is different from the 607 (Unwanted) SIP response code, where the called party rejected the call. The response can include contact information that blocks the call in the Call-Info header.
openSIPS Installation Steps

openSIPS Installation Steps

openSIPS is a multi-purpose SIP server that is used by many telephony service providers and offers Class 4, Class 5, wholesale VoIP, enterprise PBX, virtual PBX, SBC, load balancing IMS platforms, call centers features and more. In this article, you can find the installation steps of openSIPS on Debian 10.

openSIPS is a high performance SIP server running on Linux that needs very little resources. Therefore, many telecom operators develop solutions with openSIPS. If you want to use openSIPS in your VoIP applications, you can follow the installation instructions below.

openSIPS Installation Steps

1. Components Used in openSIPS Installation & Versions:

  • Debian v10 (Buster) x64 minimal install (netinst)
  • OpenSips v3.0
  • OpenSips GUI v8.3.0
  • Apache v2.4
  • PHP v7.3
  • MariaDB v10

2. Pre Installation Tasks

To install openSIPS, you will first need a fresh Debian installation. You can download and install the amd64 netinst CD image from this link. Debian is very easy to install, you can also install it by following this video that I prepared.

After installing Debian, complete the installation of the following packages:

apt update && apt upgrade -y && apt -y install m4 git nano sudo curl dbus apache2 lsb-release

Normally, you can install the “monit” package as an option for monitoring, but at the time I wrote the article, it was removed from debian repos due to some vulnerabilities on the monit package. In case the situation changes, you can find the related setup command below:

apt -y install monit

3. PHP Installation

First install dependencies:

apt -y install curl apt-transport-https ca-certificates

Add PHP repo:

wget -O /etc/apt/trusted.gpg.d/php.gpg echo "deb $(lsb_release -sc) main" > \ /etc/apt/sources.list.d/php.list 

After that, install PHP packages:

apt update && apt -y install php7.3 php7.3-gd php7.3-mysql php7.3-xmlrpc php-pear php7.3-cli php-apcu php7.3-curl php7.3-xml libapache2-mod-php7.3 

Install PHP MDB2 library with pear:

pear install MDB2#mysql

Edit PHP.ini file and change short_open_tag variable to On:

sed -i "s#short_open_tag = Off#short_open_tag = On#g" /etc/php/7.3/apache2/php.ini

4. MariaDB Installation

Get gpg keys needed for MariaDB repo and install necessary packages:

apt-key adv --recv-keys --keyserver hkp:// 0xF1656F24C74CD1D8 curl -sS | sudo bash apt update && apt -y install mariadb-server 

After that edit my.cnf file as below:

nano /etc/mysql/my.cnf

To disable Strict mode and use default openSIPS latin1 character set, add these lines under [mysqld] header:

character-set-server = latin1 

Restart MariaDB service:

systemctl restart mariadb

5. openSIPS Installation

Add gpg key:

apt -y install dirmngr && apt-key adv --keyserver --recv-keys 049AD65B

Add openSIPS repos:

echo "deb $(lsb_release -sc) 3.0-releases" >/etc/apt/sources.list.d/opensips.list 
echo "deb $(lsb_release -sc) cli-nightly" >/etc/apt/sources.list.d/opensips-cli.list 

Install openSIPS packages:

apt update && apt -y install opensips opensips-cli opensips-*-module opensips-*-modules python3-mysqldb python3-sqlalchemy python3-sqlalchemy-utils 

6. Database Installation

Create opensips user on MariaDB and grant rights:

mysql -p 
CREATE USER 'opensips'@'localhost' IDENTIFIED BY 'opensipsrw'; 
GRANT ALL PRIVILEGES ON opensips.* TO 'opensips'@'localhost'; 

Run database installation script:

opensips-cli -x database create 

The script will ask you the database URL. Enter mysql://opensips:opensipsrw@localhost and choose default (install all tables).

7. Generating Configuration File

Run configuration generator script to generate configuration file:


Choose GenerateOpenSIPS Script > Residential Script > Configure Residential Script. Choose all items other than TLS by using space bar. Use Q to go to previous menu and schoose Generate Residential Script. Script will generate a configuration file and will promt the file name on screen. Replace opensips.cfg file with the generated one and give necessary rights:

mv /etc/opensips/opensips.cfg /etc/opensips/opensips.cfg.orig 
cp /etc/opensips/[üretilen konfig dosyası] /etc/opensips/opensips.cfg 
chmod 644 /etc/opensips/opensips.cfg 

8. Additional Configurations:

Write server IP address in opensips.cfg file:

nano /etc/opensips/opensips.cfg

write server IP addresses in two lines starting with listen= :


Then check if the configuration file is valid or not:

opensips -C /etc/opensips 

If there is an error in the file, it will appear on the screen. Correct the errors, otherwise run the opensips service with the new configuration file by using the following command:

systemctl restart opensips 

9. GUI Installation

Download openSIPS GUI via git:

git clone -b 8.3.0 /var/www/opensips-cp

Create openSIPS GUI table on database:

cd /var/www/opensips-cp/config 
mysql -p opensips < db_schema.mysql 

10. Regular Collection of Statistics

Add the necessary script into cron.d folder and restart cron service:

cd /var/www/opensips-cp/config
cp tools/system/smonitor/opensips_stats_cron /etc/cron.d/
systemctl restart cron

11. Monit Configuration (Optional)

Add the necessary line into monitrc file and restart monit service:

echo -e "set httpd port 2812 and\nallow localhost" >> /etc/monit/monitrc
systemctl restart monit

12. Global Configurations

Open GUI config PHP file and edit as follows:

nano +30 /var/www/opensips-cp/config/ 
// monit host:port 

13. Apache Configuration

Define Virtual Hosts on Apache by using the commands below:

cat >> /etc/apache2/sites-available/opensips.conf << EOF 
<VirtualHost *:80> 

DocumentRoot /var/www/opensips-cp 

<Directory /var/www/opensips-cp/web>
     Options Indexes FollowSymLinks MultiViews
     AllowOverride None
     Require all granted 

<Directory /var/www/opensips-cp>
     Options Indexes FollowSymLinks MultiViews
     AllowOverride None
     Require all denied 
Alias /cp /var/www/opensips-cp/web 

<DirectoryMatch "/var/www/opensips-cp/web/tools/.*/.*/(template|custom_actions|lib)/">
      Require all denied 



Disable default site, enable openSIPS GUI site, change owner of the folder and restart Apache:

a2dissite 000-default 
a2ensite opensips 
chown -R www-data. /var/www/opensips-cp 
systemctl restart apache2 

Finally the installation is finished. Use http://ipadress/cp URL with admin / opensips credentials to access openSIPS GUI.

How to Install & Configure TURN Server (coTURN)

How to Install & Configure TURN Server (coTURN)

This blog page covers how to install and configure coTURN server for your SIP or WebRTC projects (like Jitsi Meet) to allow users behind restrictive firewalls or proxies to connect.

What is TURN?

TURN stands for Traversal Using Relays around NAT. Similar as STUN, it is a network protocol / packet format (IETF RFC 5766) used to assist in the discovery of paths between peers on the Internet. It differs from STUN in that it uses a public relay to transfer packets between peers. TURN is used to exchange media packets when no other option is available. So that it consumes server resources and has an increased latency due to the extra hop in peer to peer connection.

The time when you must use TURN is when one of the peers is behind a symmetric NAT and the other is behind either a symmetric NAT or port-restricted NAT. The frequency of cases where a relay is necessary is around %10 of the overall connections, since STUN is enough for most cases.

Install coTURN Server

Audio / Video based services requires a wide range of UDP ports to be available for WebRTC. In some network restricted sites, such as those behind NAT or a firewall that restricts outgoing UDP connections, users may be unable to make outgoing UDP connections to your media server.

TURN protocol is designed to allow UDP communication flows to bypass NAT or firewalls by forcing the client to connect to the TURN server, and then force TURN server to connect to the destination on their behalf.

Using a TURN server under your control improves the success of connections to your multimedia application and also improves user privacy, since it acts like a proxy so that peers will no longer be sending their IP address information to a public STUN server.

Required Hardware

TURN protocol is not really CPU or memory intensive. Additionally, since it’s only used during connection setup (for STUN) and as a fallback for users who would otherwise be unable to connect, the bandwidth requirements aren’t particularly high. For a moderate number of connections, a single small VPS configuration is usually enough. Here you can find my reccomendations to install coTURN:

  • At least two vCPUs
  • 4GB Memory.
  • 20GB HDD. SSD can be used, but not mandatory.
  • The most important thing is the networking performance.
    • Low jitter (less than 30ms)
    • Low latency (less than 150ms)
    • Enough bandwidth to handle relayed media streams in both directions.

Having the server behind NAT (like on Amazon EC2) is OK, but all incoming UDP and TCP connections on any port (TCP 80 & 443, UDP 3478, 10000-20000) must be forwarded to coTURN server and not firewalled.

Required Software

I recommend using a minimal server installation of Debian with netinst or Ubuntu. Since coTURN software uses port TCP 443, the server which coTURN will be installed cannot have any other web applications running.

coTURN is already available in the Debian and Ubuntu repositories and it can be installed with apt-get:

$ sudo apt-get update
$ sudo apt-get install coturn

Please note that coTURN will not start automatically until the configuration is finished. You can find the configuration tasks in below.

DNS Entry For coTURN

You need to setup a fully qualified domain name (FQDN) that resolves the external IP address of your coTURN server. You’ll use this domain name to generate a TLS certificate.

Generating TLS Certificates

You can use certbot to generate free TLS certificates from Let’s Encrypt. To setup certbot, enter the following commands on your coTURN server:

$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install certbot

Note: If you face with add-apt-repository command not found error, please use sudo apt-get install software-properties-common command to install the necessary packets.

You can then run a certbot command like the following to generate the certificate, replacing with the domain name of your TURN server:

$ sudo certbot certonly --standalone --preferred-challenges http \
    --deploy-hook "systemctl restart coturn" \

Current versions of the certbot command set up automatic renewal by default. Note that when certbot renews the certificate, it will restart coTURN service, so coTURN will start to use the updated certificate files. This will cause an interruption on any ongoing TURN connections. You may change the certbot renewal schedule or disable automatic renewal if you like.

Configure coTURN

coTURN configuration is stored in /etc/turnserver.conf file. There are a lot of options and all of them are documented in comments in that file. I include a sample configuration below with comments as the recommended settings, also with notes in places where customization is needed.

You can replace the contents /etc/turnserver.conf with the file below and make these changes:

  • Replace with the hostname of your TURN server
  • Change the values in bold with your choices.

You can see an example config file below:
external-ip= #or just write the external ip 

You can now start the COTURN service with this command:

$ systemctl start coturn

Running coTURN as a Service

The Debian / Ubuntu package for coTURN requires that you edit a file to enable at startup. Edit /etc/default/coturn file and uncomment the following line:


That’s it! coTURN install is complete. Now you have an up and runnning TURN server!

Testing Your TURN Server

To test your coTURN server, you can use Trickle-Ice testing tool. Go to trickle-ice webpage and enter following:

STUN or TURN URI : turn:Your Public IP Address:3478
TURN username: Username
TURN password: Password

Then click Add Server button and then click Gather Candidates button. If everything works well, you should see Done as final result.