-
Notifications
You must be signed in to change notification settings - Fork 0
README
The TURN Server project contains the source code of a TURN server and TURN client messaging library. Also, some extra programs provided, for testing-only purposes.
See the INSTALL file for the building instructions.
After the build, you will have the following binary images:
- turnserver: TURN Server relay. The compiled binary image of this program is located in bin/ sub-directory.
-
turnadmin: TURN administration tool. This tool can be used for:
- generation of TURN keys for the user accounts. For security reasons, we do not recommend storing passwords openly. The better option is to use pre-processed "keys" which are then used for authentication. These keys are generated by turnadmin.
- listing available users in the database.
- adding and deleting users in the database.
- updating user passwords.
- setting shared secret for TURN REST API.
- turnutils_uclient: emulates multiple UDP,TCP,TLS or DTLS clients. The compiled binary image of this program is located in bin/ sub-directory.
- turnutils_peer: a simple stateless UDP-only "echo" server, to be used as the final server in relay pattern ("peer"). For every incoming UDP packet, it simply echoes it back. (this program is provided for the testing purposes only !) When the test clients are communicating in the client-to-client manner, this component is not needed. The compiled binary image of this program is located in bin/ subdirectory.
- turnutils_stunclient: a simple STUN client example that implements RFC 5389 and RFC 5780. The compiled binary image of this program is located in bin/ subdirectory.
- turnutils_rfc5769check: a utility that checks the correctness of the STUN/TURN protocol implementation. This program will perform several checks and print the result on the screen. It will exit with 0 status if everything is OK, and with (-1) if there was an error in the protocol implementation.
In the "examples/scripts" subdirectory, you will find the examples of command lines to be used to run the programs. The scripts are meant to be run from examples/ subdirectory, for example:
$ cd examples
$ ./scripts/longtermsecure/secure_relay.sh
$ turnserver [flags] [-n | -c <config-file>] [ --db=<sqlite-db-file> |--userdb=<sqlite-db-file> | --psql-userdb=<db-conn-string> | --mysql-userdb=<db-conn-string> ] [options]
$ turnserver -h
$ turnadmin [command] [options]
$ turnadmin [ -h | --help]
It was designed to simulate multiple clients. It uses asynch IO API in libevent to handle multiple clients. A client connects to the relay, negotiates the session, and sends multiple (configured number) messages to the server (relay), expecting the same number of replies. The length of the messages is configurable. The message is an arbitrary octet stream, but it can be configured as a string. The number of the messages to send is configurable.
$ turnutils_uclient [-tSvsyhcxg] [options] <TURN-Server-IP-address>
turnutils_peer is a simple UDP-only echo backend server. This application is used for the test purposes only, as a 'peer' for the turnutils_uclient application.
$ turnutils_peer [-v] [options]
It sends a STUN request and shows the reply information.
$ turnutils_stunclient [options] <STUN-Server-IP-address>
It tests the protocol implementation against the test vectors predefined in RFC 5769 and prints the results of the tests on the screen.
$ turnutils_rfc5769check
PROTOCOL CHECK UTILITY WIKI PAGE
In the lib/ sub-directory the build process will create TURN client messaging library. In the include/ sub-directory, the necessary include files will be placed. The C++ wrapper for the messaging functionality is located in TurnMsgLib.h header. An example of C++ code can be found in stunclient.c file.
In the original archive tree, the command:
$ man -M man turnserver
will give you the man page.
After the proper installation, the command:
$ man turnserver
will give you the same man page.
In the docs/html subdirectory of the original archive tree, you will find the client library reference. After the installation, it will be placed in PREFIX/share/doc/turnserver/html.
When the TURN Server starts, it makes efforts to create a log file turnserver_<pid>.log
in the following directories:
- /var/log
- /log/
- /var/tmp
- /tmp
- current directory
If all efforts failed (due to the system permission settings) then all log messages are sent only to the standard output of the process.
This behavior can be controlled by --log-file and --no-stdout-log options (see turnserver help).
TURN Server can be a part of the cluster installation. But, to support the "even port" functionality (RTP/RTCP streams pairs) the client requests from a particular IP must be delivered to the same TURN Server instance, so it requires some networking setup massaging for the cluster. The reason is that the RTP and RTCP relaying endpoints must be allocated on the same relay IP. It would be possible to design a scheme with the application-level requests forwarding (and we may do that later) but it would affect the performance.
Performance Optimization and Load Balance WIKI PAGE
/etc/turnserver.conf
/var/db/turndb
/usr/local/etc/turnserver.conf
/usr/local/var/db/turndb
/var/lib/turn/turndb
classic STUN RFC 3489
new STUN RFC 5389
TURN RFC 5766
TURN-TCP extension RFC 6062
TURN IPv6 extension RFC 6156
STUN/TURN test vectors RFC 5769
STUN NAT behavior discovery RFC 5780
A REST API For Access To TURN Services draft-uberti-behave-turn-rest-00
project page: https://github.com/coturn/coturn/
forum: https://groups.google.com/forum/?fromgroups=#!forum/turn-server-project-rfc5766-turn-server/
Oleg Moskalenko [email protected]
design, coding
Gabor Kovesdan, http://kovesdan.org :
FreeBSD packaging (since v1.5.2.6);
Daniel Pocock, http://danielpocock.com :
Debian packaging (since v1.8.3.6);
John Selbie (jselbie) :
Stuntman interoperability, RFC5780 fixes (since v1.8.3.6);
Lee Sylvester [email protected] :
Status and statistics - ideas and pilot implementation (since v1.8.4.0);
Erik Johnston [email protected] :
Access Control Lists, 2013 (since v1.8.5.0);
Roman Lisagor [email protected] :
Testing, code optimization (since v1.8.6.0);
Vladimir Tsanev [email protected] :
configure script and Makefile fixes, Arch Linux port (since v1.8.6.1);
Po-sheng Lin [email protected] :
Libevent dependencies cleaning (since v2.0.1.1);
Peter Dunkley [email protected] :
CentOS/Fedora port (since v2.6.6.1)
Mutsutoshi Yoshimoto [email protected]
Federico Pinna [email protected]
Bradley T. Hughes [email protected]