This package provides a library that adds ZRTP support to the GNU ccRTP stack and serves as library for other RTP stacks (PJSIP, GStreamer). Phil Zimmermann developed ZRTP to allow ad-hoc, easy to use key negotiation to setup Secure RTP (SRTP) sessions. GNU ZRTP works together with GNU ccRTP (1.5.0 or later) and provides a ZRTP implementation that can be directly embedded into client and server applications.
The GNU ZRTP implementation is compliant to RFC 6189 and adds some more algorithms. Currently GNU ZRTP C++ supports the following features:
Some features like preshared mode are not supported but the GNU ZRTP C++ implementation defines the necessary external interfaces and functions for these enhanced features.
Note: The Elliptic curves Cure25519 and Curve3617 are available only if you select the crypto standalone mode during build.
The newer verisons (starting with 4.1) implement an extensible mechanisms to define algorithm selection policies that control selection of Hash, symmetric cipher, and the SRTP authentication. Currently two policies exist: Standard and PreferNonNist. The Standard policy selects algorihms based on the preferences (order) in the Hello packet, the PreferNonNist policy prefers non-NIST algorithms, for example Skein and Twofish, if the selected public key (Diffie-Hellman) algorithm is also one of the non-NIST algorithms. This is fully backward compatible and in-line with RFC6189.
This release also provides SDES support. The SDES implementation does not support all of the fancy stuff but is usable in most cases. This implementation however supports the new SDES crypto mixing to overcome some security issues for SIP forking. Please look for draft-zimmermann-mmusic-sdesc-mix-00
.
During the development of ZRTP and its sister implementation ZRTP4J (the Java version of the ZRTP) Phil Zimmermann, his developers, and I worked together to make sure Phil's Zfone implementation and the GNU ZRTP implementations can work together.
The ZRTP4J implementation is a copycat of the original C++ code. I used the same overall class structure and copied a lot of C++ functionality to Java. Of course some Java adaptation were done, for example to overcome the problem of non-existing pointers :-), thus I use some non-obvious array handling. If you are interessted in the Java implementation of ZRTP then you may have a look here. The Jitsi project uses the Java implementation. Jitsi is a powerfull communication client and is definitely worth a look.
To enable C based code to use ZRTP C++ I did a C wrapper that offers the same functionality to C based RTP implementations. The first use of the ZRTP C wrapper was for the PJSIP library, actually the RTP part of this library. The ZRTP handler for PJSIP is here. This port enables PJSIP based clients to use ZRTP. One of the first clients that uses this feature is CSipSimple, an very good open source Android SIP client.
The first application that demonstrated the embedded ZRTP was Minisp (now defunct). Minisip has it's own RTP stack and the very first version of this embedded ZRTP implementation worked together with this specific RTP stack.
A few weeks later I implemented the GNU ccRTP glue code and ZRTP became part of the official GNU ccRTP project and was named GNU ZRTP C++. The Twinkle softphone uses GNU ccRTP and GNU ZRTP C++ since it's 0.8.2 release and Michel de Boer, the implementor of Twinkle, created a nice user interface. All following versions of Twinkle include GNU ZRTP C++ as well.
I changed the license of the ZRTP core source files from GPL to LGPL. Other sources files may have own license. Please refer to the copyright notices of the files.
Thus most of this library is licensed under the GNU LGPL, version 3 or later.
For further information refer to the ZRTP FAQ and the GNU ZRTP howto. Both are part of the GNU Telephony wiki and are located in its documentation category.
Source code in the directory clients/tivi
and below is not licensed under the GNU LGPL and is for reference and review only. Refer to the copyright statments of the source code in these directories, in particular the sqlite3 sources which have their own license.
Since version 1.6 GNU ZRTP C++ supports the cmake based build process only. The cmake build process is simpler than the GNU automake/autoconf process. To build GNU ZRTP C++ perform the following steps after you unpacked the source archive or pulled the source from Github:
cd <zrtpsrc_dir> mkdir build cd build cmake .. make
The CMakeLists.txt supports several options. If you don't specify any options then cmake
generates the build that supports GNU ccRTP library and it uses the standalone cryptographic modules, thus no it's not necessary to install an cryptographic library on the system. Optionally you may configure ZRTP to use sqlite3 instead of a simple file to store the ZRTP cache data. For example
cmake -DSQLITE=true ..
creates the build files that use sqlite3.
Please have a look at the CMakeLists.txt
for other options.
Running cmake in a separate build
directory is the preferred way. Cmake and the following make
generate all files in or below the build directory. Thus the base directory and the source directories are not polluted with *.o
, *.la
, or other files that result from the build process. You may delete the build directory and create a new one to start from fresh (this is the ultimate make clean
:-) ) or you may create a second directory to build with different settings without mixing the two builds.
The CMake files support creation of an Android.mk
file for the Tivi client and may give you an idea how to do it for other clients. The generated Android.mk
generates buildinfo_*.c
files in the root directory. You may delete these files after the Android static libraries are ready.
Since version 4.1.1 the example Android build files require NDK r9c.