A set of turnutils_* programs provides some utility functionality to be used for
testing and for setting up the TURN server.
- 1.
- turnutils_uclient: emulates multiple UDP,TCP,TLS or DTLS clients.
(this program is provided for the testing purposes only !) The compiled
binary image of this program is located in bin/ sub-directory.
WARNING: the
turnutils_uclient program is a primitive client application.
It does not implement the re-transmission pattern that is necessary for a
correct TURN client implementation. In TURN, the retransmission burden is
lying almost entirely on the client application. We provide the messaging
functionality in the client library, but the client must implement the correct
Networking IO processing in the client program code.
- 2.
- 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 (when the
" turnutils_uclient" program is used with
"-y" option) then the turnutils_peer is not
needed.
The compiled binary image of this program is located in bin/ subdirectory.
- 3.
- turnutils_stunclient: a simple STUN client example. The compiled
binary image of this program is located in bin/ subdirectory.
- 4.
- turnutils_rfc5769check: a utility that checks the correctness of
the STUN/TURN protocol implementation. This utility is used only for the
compilation check procedure, it is not copied to the installation
destination.
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
=====================================
NAME¶
turnutils_uclient - this client emulation application
is supplied for the test purposes only.
SYNOPSIS¶
$
turnutils_uclient [
-tTSvsyhcxg] [options]
<TURN-Server-IP-address>
DESCRIPTION¶
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.
- Flags:
- -t
- Use TCP for communications between client and TURN server (default is
UDP).
- -T
- Use TCP for the relay transport (default - UDP). Implies options
-t, -y, -c, and ignores flags and options -s,
-e, -r and -g.
- -P
- Passive TCP (RFC6062 with active peer). Implies -T.
- -S
- Secure SSL connection: SSL/TLS for TCP, DTLS for UDP.
- -U
- Secure unencrypted connection (suite eNULL): SSL/TLS for TCP, DTLS for
UDP.
- -v
- Verbose.
- -s
- Use "Send" method in TURN; by default, it uses TURN
Channels.
- -y
- Use client-to-client connections: RTP/RTCP pair of channels to another
RTP/RTCP pair of channels. with this option the turnutils_peer
application is not used, as the allocated relay endpoints are talking to
each other.
- -h
- Hang on indefinitely after the last sent packet.
- -c
- Do not create rtcp connections.
- -x
- Request IPv6 relay address (RFC6156).
- -X
- IPv4 relay address explicitly requested.
- -g
- Set DONT_FRAGMENT parameter in TURN requests.
- -A
- use short-term credentials mechanism for authentication. By default, the
program uses the long-term credentials mechanism if authentication is
required.
- -D
- Do mandatory channel padding even for UDP (like pjnath).
- -N
- do negative tests (some limited cases only).
- -R
- do negative protocol tests.
- -O
- DOS attack mode.
- -H
- SHA256 digest function for message integrity calculation. Without this
option, by default, SHA1 is used.
- -M
- Use TURN ICE Mobility.
- -I
- Do not set permissions on TURN relay endpoints (for testing the
non-standard server relay functionality).
- -G
- Generate extra requests (create permissions, channel bind).
- -B
- Random disconnect after a few initial packets.
- Options with required values:
- -l
- Message length (Default: 100 Bytes).
- -i
- Certificate file (for secure connections only, optional).
- -k
- Private key file (for secure connections only).
- -E
- CA file for server certificate verification, if the server certificate to
be verified.
- -p
- TURN Server port (Defaults: 3478 unsecure, 5349 secure).
- -n
- Number of messages to send (Default: 5).
- -d
- Local interface device (optional, Linux only).
- -L
- Local IP address (optional).
- -m
- Number of clients (Default: 1, 2 or 4, depending on options).
- -e
- Peer address.
- -r
- Peer port (Default: 3480).
- -z
- Per-session packet interval in milliseconds (Default: 20).
- -u
- STUN/TURN user name.
- -w
- STUN/TURN user password.
- -W
- TURN REST API authentication secret. Is not compatible with -A
flag.
- -C
- This is the timestamp/username separator symbol (character) in TURN REST
API. The default value is :.
- -F
- Cipher suite for TLS/DTLS. Default value is DEFAULT.
See the examples in the "examples/scripts" directory.
======================================
NAME¶
turnutils_peer - a simple UDP-only echo backend
server.
SYNOPSYS¶
$
turnutils_peer [
-v] [options]
DESCRIPTION¶
This application is used for the test purposes only, as a peer for the
turnutils_uclient application.
- Options with required values:
- -p
- Listening UDP port (Default: 3480).
- -d
- Listening interface device (optional)
- -L
- Listening address of turnutils_peer server. Multiple listening
addresses can be used, IPv4 and IPv6. If no listener address(es)
defined, then it listens on all IPv4 and IPv6 addresses.
- -v
- Verbose
========================================
NAME¶
turnutils_stunclient - a basic STUN client.
SYNOPSIS¶
$ turnutils_stunclient [options] <STUN-Server-IP-address>
DESCRIPTION¶
It sends a "new" STUN RFC 5389 request (over UDP) and shows the reply
information.
- Options with required values:
- -p
- STUN server port (Default: 3478).
- -L
- Local address to use (optional).
- -f
- Force RFC 5780 processing.
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).
=====================================
NAME¶
turnutils_rfc5769check - a utility that tests the
correctness of STUN protocol implementation.
SYNOPSIS¶
$ turnutils_rfc5769check
DESCRIPTION¶
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
===================================
DOCS¶
After installation, run the command:
$ man
turnutils
or in the project root directory:
$ man
-M man
turnutils
to see the man page.
=====================================
FILES¶
/etc/turnserver.conf
/etc/turnuserdb.conf
/usr/local/etc/turnserver.conf
/usr/local/etc/turnuserdb.conf
=================================
DIRECTORIES¶
/usr/local/share/
turnserver
/usr/local/share/doc/
turnserver
/usr/local/share/examples/
turnserver
===================================
STANDARDS¶
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
====================================
SEE ALSO¶
turnserver,
turnadmin
======================================
WEB RESOURCES¶
project page:
http://code.google.com/p/rfc5766-turn-server/
Wiki page:
http://code.google.com/p/rfc5766-turn-server/wiki/Readme
forum:
https://groups.google.com/forum/?fromgroups=#!forum/turn-server-project-rfc5766-turn-server/
======================================
AUTHORS¶
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@crocodilertc.net>
Mutsutoshi Yoshimoto <mutsutoshi.yoshimoto@mixi.co.jp>
Bradley T. Hughes <bradleythughes@fastmail.fm>