Provided by: rfc5766-turn-server_3.2.3.1-1_amd64 bug

GENERAL INFORMATION

       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).

       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 username/timestamp 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>

                                          28 March 2014                                   TURN(1)