TURN(1) | TURN(1) |
A set of turnutils_* programs provides some utility functionality to be used for testing and for setting up the TURN server.
The compiled binary image of this program is located in bin/ subdirectory.
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/secure_relay.sh
For more details, and for the access_token structure, read
rfc7635, and see script in examples/scripts/oauth.sh.
turnutils_uclient - this client emulation application is supplied for the test purposes only.
$ turnutils_uclient [-tTSvsyhcxg] [options] <TURN-Server-IP-address>
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. The number of the messages to send is configurable.
Flags:
Options with required values:
See the examples in the "examples/scripts" directory.
======================================
turnutils_peer - a simple UDP-only echo backend server.
$ turnutils_peer [-v] [options]
This application is used for the test purposes only, as a peer for the turnutils_uclient application.
Options with required values:
========================================
turnutils_stunclient - a basic STUN client.
$ turnutils_stunclient [options] <STUN-Server-IP-address>
It sends a "new" STUN RFC 5389 request (over UDP) and shows the reply information.
Options with required values:
The turnutils_stunclient program checks the results of the first request, and if it finds that the STUN server supports RFC 5780 (the binding response reveals that) then the turnutils_stunclient makes a couple more requests with different parameters, to demonstrate the NAT discovery capabilities.
This utility does not support the "old" "classic" STUN protocol (RFC 3489).
=====================================
turnutils_rfc5769check - a utility that tests the correctness of STUN protocol implementation.
$ turnutils_rfc5769check
turnutils_rfc5769check tests the correctness of STUN protocol implementation against the test vectors predefined in RFC 5769 and prints the results of the tests on the screen. This utility is used only for the compilation check procedure, it is not copied to the installation destination.
Usage:
$ turnutils_rfc5769check
=====================================
turnutils_natdiscovery - a utility that discovers NAT mapping and filtering behavior according RFC5780.
$ turnutils_natdiscovery [options] <STUN-Server-FQDN-or-IP-address>
turnutils_natdiscovery discovers the NAT Mapping and Filtering behavior, to determine if that NAT is currently using Endpoint-Independent, Address-Dependent, or Address and Port-Dependent Mapping and/or to determine if that NAT is currently using Endpoint-Independent, Address-Dependent, or Address and Port-Dependent Filtering.
Use either -m, -f, -c, -H flag to discover NAT behavior.
Flags:
Options with required values:
Usage:
$ turnutils_natdiscovery -m -f stun.example.com
=====================================
turnutils_oauth - a utility that helps OAuth access_token generation/encryption and validation/decyption
$ turnutils_oauth [options]
turnutils_oauth utilitiy provides help in OAuth access_token encryption and/or decryption with AEAD (Atuthenticated Encryption with Associated Data). It helps for an Auth Server in access_token creation, and also for debugging purposes it helps the access_token validation and decryption. This utility inputs all the keys and lifetimes and any related information that are needed for encryption or decryption of an access_token. It outputs a JSON with all OAuth PoP parameters that need to pass to the client. Output is generated accoriding RFC7635 Appendix B, Figure 8. This utility could help to build an Auth Server service, but be awere that this utility does not generate "session key" / "mac_key" and not verifies lifetime of "session key" / "mac_key" or "Auth key". For more details, and for the access_token structure, read rfc7635, and see the example in examples/scripts/oauth.sh.
Use either -e and/or -d flag to encrypt or decrypt access_token.
Flags:
Options with required values:
Usage:
$ turnutils_natdiscovery
===================================
After installation, run the command:
$ man turnutils
or in the project root directory:
$ man -M man turnutils
to see the man page.
=====================================
/etc/turnserver.conf
/var/db/turndb
/usr/local/var/db/turndb
/var/lib/turn/turndb
/usr/local/etc/turnserver.conf
=================================
/usr/local/share/turnserver
/usr/local/share/doc/turnserver
/usr/local/share/examples/turnserver
===================================
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
====================================
turnserver, turnadmin
======================================
project page:
https://github.com/coturn/coturn/
Wiki page:
https://github.com/coturn/coturn/wiki
forum:
https://groups.google.com/forum/?fromgroups=#!forum/turn-server-project-rfc5766-turn-server/
======================================
Oleg Moskalenko <mom040267@gmail.com>
Gabor Kovesdan http://kovesdan.org/
Daniel Pocock http://danielpocock.com/
John Selbie (jselbie@gmail.com)
Lee Sylvester <lee@designrealm.co.uk>
Erik Johnston <erikj@openmarket.com>
Roman Lisagor <roman@demonware.net>
Vladimir Tsanev <tsachev@gmail.com>
Po-sheng Lin <personlin118@gmail.com>
Peter Dunkley <peter.dunkley@acision.com>
Mutsutoshi Yoshimoto <mutsutoshi.yoshimoto@mixi.co.jp>
Federico Pinna <fpinna@vivocha.com>
Bradley T. Hughes <bradleythughes@fastmail.fm>
Mihaly Meszaros <misi@majd.eu>
29 January 2019 |