Building standalone core library on OS X

[mattmm17]

CMake files provide no method to build the standalone libzrtpcppcore library.

I am working on a project that uses the core library verison 2.3.x and looking to upgrade to enable B256 support. The 2.3.x version allowed building just the core library by doing a cmake -Denable-ccrtp=false.

3.2.3 provides no such option. Enabling ccrtp creates other issues. (Unless I am missing something there is no easy way to install ccrtp-dev on mac.) Building the TIVI client works, however the core library is not created.

Is there an easy way to enable building just the core library? I have compared the CMakeList files and nothing jumps out.

Thanks for your time,

Matt.

[wernerd]

Sorry for the long delay, busy times :-)

I've just push a new pre-release in the ZRTP develop branch on Github. In this pre-release I added the feature to build a standalone (core) library.

Please check for the parameter -DCORE_LIB for the cmake call. You may add other parameters in addition, for example to have a SQlite base cache or a version of ZRTP that does not require openSSL or gcrypt libraries.

Please give it a try and in case of problems just drop a note.

Werner

Am 21.10.2013 22:04, schrieb mattmm17:

CMake files provide no method to build the standalone libzrtpcppcore library.

I am working on a project that uses the core library verison 2.3.x and looking to upgrade to enable B256 support. The 2.3.x version allowed building just the core library by doing a cmake -Denable-ccrtp=false.

3.2.3 provides no such option. Enabling ccrtp creates other issues. (Unless I am missing something there is no easy way to install ccrtp-dev on mac.) Building the TIVI client works, however the core library is not created.

Is there an easy way to enable building just the core library? I have compared the CMakeList files and nothing jumps out.

Thanks for your time,

Matt.

---

Reply to this email directly or view it on GitHub: https://github.com/wernerd/ZRTPCPP/issues/9

---

Werner Dittmann [email protected] Tel +49 173 44 37 659 PGP key: 82EF5E8B

[mattmm17]

Thanks. I will not get back to this for a week or two, but I'll update this ticket if there's an issue.

Matt.

[NicholasDong]

Hi Werner, I am working on a VOIP project based on SIP protocol. And I have implemented the SIP and RTP/RTCP part by myself, so now the program works well. But I want to add ZRTP/SRTP in my project to increase the security. So now I have a question that how to use your ZRTPCPP lib without the ccRTP in my project because I finished the RTP part and only want to use libzrtpcore to add ZRTP in my project.

I now use "cmake -DCORE_LIB=true .." to build standalone core lib, but I have no idea how to use it independently. Hope you can give me some guide or some examples .

Waiting for your help and Thanks very much!

Nick

[wernerd]

Hi Nicholas,

the ZRTP core library does not contain what I call the "glue code". This is the code that links (or "glues together") the ZRTP libaray and the RTP stack and also provides some system functions.

ZRTP requires that the glue code implements some callback functions that it can use. Example of such a glue code are:

a project that integrates the ZRTP lib with PJSIP, the C module 'transport_zrtp.c'

if the code that links the ZRTP lib with the PJSIP code, here the RTP implementation of PJSIP: https://github.com/wernerd/ZRTP4PJ

Another (bit mor complex example) is the code for "gstreamer", here it's the zrtp_filter' that implements the glue code: https://github.com/wernerd/gstzrtp

An last but not least the ccRTP project. Here the module in the ZRTPCPP project clients/ccrtp/ZrtpQueue.cpp implements the code.

In general the ZRTP glue code sits between the RTP stack and the application:

• monitors the RTP flow
• looks for ZRTP packets during the ZRTP protocol phase, usually at the beginning of a call, and forwards these packets to the ZRTP lib
• if secure state is reached the glue code takes the RTP/SRTP packets and hands them to SRTP to protct/unprotect them, the forwards them
• implements callback that ZRTP lib can use to send ZRTP packets, to queue timers for timeout handling, callback to switch security, callbacks to the app layer to inform about events

HAve a look into the above mentioned glue code modules. I usually added some documentation to the relevant header files.

Werner

Am 20.10.2015 um 11:20 schrieb NicholasDong:

Hi Werner, I am working on a VOIP project based on SIP protocol. And I have implemented the SIP and RTP/RTCP part by myself, so now the program works well. But I want to add ZRTP/SRTP in my project to increase the security. So now I have a question that how to use your ZRTPCPP lib without the ccRTP in my project because I finished the RTP part and only want to use libzrtpcore to add ZRTP in my project.

I now use "cmake -DCORE_LIB=true .." to build standalone core lib, but I have no idea how to use it independently. Hope you can give me some guide or some examples .

Waiting for your help and Thanks very much!

Nick

— Reply to this email directly or view it on GitHub https://github.com/wernerd/ZRTPCPP/issues/9#issuecomment-149489589.

Werner Dittmann email: [email protected] cell: +49 173 44 37 659 PGP key: 82EF5E8B

[NicholasDong]

Really appreciate your answer, I will study the glue code you mentioned.

Nick

[dronord]

Werner, would you like to fix GoRTP? simpleRTP() does not work. Sorry for another thread. %)

[wernerd]

May take a few days, I need to update my Go enviroment first. Actually I'm suprised that GoRTP is used at all after such a long time :-)

Werner

Am 22.10.2015 um 11:56 schrieb dronord:

Werner, would you like to fix GoRTP? simpleRTP() does not work. Sorry for another thread. %)

— Reply to this email directly or view it on GitHub https://github.com/wernerd/ZRTPCPP/issues/9#issuecomment-150165859.

Werner Dittmann email: [email protected] cell: +49 173 44 37 659 PGP key: 82EF5E8B

[wernerd]

Am 22.10.2015 um 14:48 schrieb Werner Dittmann:

May take a few days, I need to update my Go enviroment first. Actually I'm suprised that GoRTP is used at all after such a long time :-)

I just pushed back changes. I tested this with the latest go 1.5.1.

After setting the GOPATH to the correct directory, then running

go test net/rtp # runs the unit tests go install net/rtpmain # install in $GOPATH/bin $GOPATH/bin/rtpmain # runs example program

go run src/net/rtpmain/rtpmain.go # another way to run the esample prog

If you see any error please report, thanks.

Werner

Werner

Am 22.10.2015 um 11:56 schrieb dronord:

Werner, would you like to fix GoRTP? simpleRTP() does not work. Sorry for another thread. %)

— Reply to this email directly or view it on GitHub https://github.com/wernerd/ZRTPCPP/issues/9#issuecomment-150165859.

Werner Dittmann email: [email protected] cell: +49 173 44 37 659 PGP key: 82EF5E8B

[NicholasDong]

Hi Werner, Thanks for your last reply, another question here. I am trying to create my own "glue code" now, as you implemented in zrtpQueue.cpp, the zrtpQueue links GNU ZRTP core and the ccRTP. However in my case, for some reasons, I can not let the glue code extends the RTP part(such as send ZRTP via RTP). so I want to create a independent "ZrtpQueue" part to implement the required functions(send ZRTP via my own socket), the basic relationship as:

          +----------+
          |  RTP     |
          |  SRTP   |
         +----------+
               |
               |
          +----------+                  +----------+             +----------+
          |  SIP      |  ---------------|  glue    |------------|  ZRTP  |
          |           |                 |   code  |             |  core     |
         +----------+                   +----------+             +----------+

The application(SIP) now as a intermediary, so the glue code and the RTP can communicate with SIP.such as get the SSRC, transport the shared secret, and so on.

I wonder if this architecture can work, or can you give me some advice?

Nick

[wernerd]

IMHO you need a bi-directional data path between the ZRTP glue code and the SIP/RTP part, similar to this:

+----------+ | RTP | | SRTP | +----------+ | . | . +-------.--+ +----------+ +----------+ | SIP '' '''''''''''''' glue | --------| ZRTP | | |----------- | code | | core | +----------+ +----------+ +----------+

The RTP/SRTP stack first sends the RTP/SRTP packets to the glue code which processes them.

• in case it detects ZRTP data it forward the data to ZRTP core, the glue code then signals to the RTP part to dismiss the packet and to listen for new packets
• ZRTP creates own data, forwards it to glue code which uses the bi-directional path to send it via RTP socket
• in case security is "on" ZRTP glue would handle the SRTP packet, decrypts the data and hands back the decrypted RTP packet to the RTP stack

I don't know how you handle audio codec, however, the RTP code should forward each RTP packet to the glue code. The glue code checks the security status and depending on this either encrypt the RTP and produce a SRTP packet or just return the RTP packets.

A simple wa to implement such a bi-directional communication, decoupled via the SIP module:

• the SIP module implement producer/consumer model: = RTP/SRTP module calls a "producer" function to queue RTP packets and then listens on a "consumer" functions for packetes returned from the glue code = the glue code listens on a "consumer" function to get data from RTP and forward its data using a "producer" function

These functions may just two simple FIFO lists and a simple "wait for data" semaphore for each list on the consumer part

You may need tow sets of this: one set for incoming RTP (from the network) and one set for outgoing RTP. Depending on the implementation and how you monitor the lists you may also need a third set: ZRTP may send packets asynchronous (timer controlled) and your code needs to handle this

To avoid blocking on the "consumer" sides you may need to define/send "empty" packets to detect if a packet should be dismissed (incoming ZRTP packets)

This is not a full blown design, jsut some quick ideas :-) .

Werner

Am 06.11.2015 um 09:24 schrieb NicholasDong:

Hi Werner, Thanks for your last reply, another question here. I am trying to create my own "glue code" now, as you implemented in zrtpQueue.cpp, the zrtpQueue links GNU ZRTP core and the ccRTP. However in my case, for some reasons, I can not let the glue code extends the RTP part(such as send ZRTP via RTP). so I want to create a independent "ZrtpQueue" part to implement the required functions(send ZRTP via my own socket), the basic relationship as:

|+----------+ | RTP | | SRTP | +----------+ | | +----------+ +----------+ +----------+ | SIP | -------------------- | glue | ----------------------| ZRTP | | | | code | | core | +----------+ +----------+ +----------+ |

The application(SIP) now as a intermediary, so the glue code and the RTP can communicate with SIP.such as get the SSRC, transport the shared secret, and so on.

I wonder if this architecture can work, or can you give me some advice?

Nick

— Reply to this email directly or view it on GitHub https://github.com/wernerd/ZRTPCPP/issues/9#issuecomment-154342603.

Werner Dittmann email: [email protected] cell: +49 173 44 37 659 PGP key: 82EF5E8B

[NicholasDong]

Hi Werner,

Thanks for your quick answer. But I have some questions:

1. Do you mean that the RTP/SRTP stack should send both the generated RTP/SRTP and received RTP/SRTP to the glue code? and why? I handle the audio codec in RTP part can the RTP/SRTP stack only send the received ZRTP packet to the glue code to processes, and directly decode the RTP or decrypt the SRTP?
2. Can the ZRTP data send through the glue code independently(the glue code only send ZRTP packet and get the peer's ZRTP through RTP stack)
3. what I want to achieve is that the glue code and the ZRTP core parts negotiate the shared secret and send it to RTP/SRTP stack to produce the SRTP packet, so the glue part only handle the ZRTP packets(directly send and received from the RTP stack)

Thanks for your patience!

Nick

[wernerd]

Am 06.11.2015 um 11:45 schrieb NicholasDong:

Hi Werner,

Thanks for your quick answer. But I have some questions: 1. Do you mean that the RTP/SRTP stack should send both the generated RTP/SRTP and received RTP/SRTP to the glue code? and why? I handle the audio

In my implementations the glue code knows if security is active or not and thus control encryption and decryption of the RTP data.

codec in RTP part can the RTP/SRTP stack only send the received ZRTP packet to the glue code to processes, and directly decode the RTP or decrypt the SRTP?

Possible, then you have to implement the "ZRTP packet detection" code somehow inside your RTP stack and forward only these packets. Then also you somehow need a functions where the glue code can inform your RTP stack (possibly via callbacks?) about the SRTP encryption parameters etc.

Then you have to enhance your RTP stack to keep track of the secutity state, setup the SRTP crypto contexts etc and process RTP/SRTP packets accordingly.

Werner

1. Can the ZRTP data send through the glue code independently(the glue code only send ZRTP packet and get the peer's ZRTP through RTP stack) 2. what I want to achieve is that the glue code and the ZRTP core parts negotiate the shared secret and send it to RTP/SRTP stack to produce the SRTP packet, so the glue part only handle the ZRTP packets(directly send and received from the RTP stack)

Thanks for your patience!

Nick

— Reply to this email directly or view it on GitHub https://github.com/wernerd/ZRTPCPP/issues/9#issuecomment-154376745.

Werner Dittmann email: [email protected] cell: +49 173 44 37 659 PGP key: 82EF5E8B