Hi, This sounds really interesting and would be a very nice and welcome addition. Let me give you my two cents: [snip] > Description: > > GNU ZRTP > GNU ZRTP is the existing ZRTP implementation that handles the ZRTP > protocol, performs necessary ZRTP computations, maintains some data in a > file etc. I implemented this part in C++ (it's stable, tested to work with > Phil Zimmermann's implementation) and it's licencse is GPL v3. Currently I > implemented a first version of a C Wrapper to make GNU ZRTP accessible to > C implementations. The C Wrapper covers the main functions already and will > be enhanced during the pj project implementation. GNU ZRTP is a library, > no requirement to have it as third party source in pjproject - it's already > available as part of the GNU ccRTP project. > This sounds fine to me. > > transport_zrtp > This is a new pjmedia transport that links into the transport stream, > similar to the current SRTP transport. Thus transport acts as a filter that > controls the flow of ZRTP, RTP, and SRTP data. This is obviously a new > module. IMHO it should live in the pjmedia source, parallel to the other > transport modules. This module will be the main development during the > planned ZRTP integration. > According to some notes on the wiki posted by PJSIP members this should be the way to go. > > SRTP-ZRTP > Instead of using the existing SRTP implementation I plan to use an own SRTP > implementation (also a C++ implementation that has a C Wrapper). Some > reasons why: the current libsrtp does not support AES 256 which is implemented > for ZRTP. In addition ZRTP defines some more modern authentiation mechanisms > in SRTP that I will implement step by step. In addition the ZRTP/SRTP module > uses either openSSL or libgcrpyt as crypto backends, thus no own implementation > of the AES cipher or bignum but reusing proven an well tested implementations. > This module would live in an apporpriate third party directory. > IMHO it might be better to integrate with the existing transport_srtp module and add the missing functionality there. Transport_zrtp could be an adapter sitting before transport_srtp which would handle the key negotiation and then encrypt the media using transport_srtp and the keys negotiated by transport_zrtp. You might want to confirm this with core PJSIP developers ;-) Regards, -- Sa?l Ibarra Corretg? AG Projects