[sip-comm-dev] First SC - Twinkle ZRTP enabled test


#1

Hello Romain, Werner,

I finally managed to make a basic setup of a Linux partition (sorry for the bit of delay on that but the boot loader somehow managed to mess up my MBR and had to do some partition recovery). Anyway, the main idea after all is that I installed Twinkle - the 1.2 version from the site, and (almost) successfully ran the first ZRTP Twinkle-SC secured call.

Now, some details about the testing:

- SC is running on WinXP SP2 (MCE) and Twinkle on openSUSE 11 ( so it's a bit of interplatform communication testing also I guess :slight_smile: )

- the test was done using no-registrar mode using the patch I adapted for SC in its latest form (for which I must take some time to try and see if I can fix it to allow registrar mode also, because like I said in the last mails it still doesn't)

- the "(almost)" part in "(almost) successfully" above refers to the fact that the audio stream sent by SC - received by Twinkle is very garbled and inconsistent (can't distinguish any word communicated through it) but I think it's a codec related problem, because this happens also in unencrypted communication; I'll try a test also using registrar mode to see how it goes on, but I really don't think this has anything to do with the problem

- the "successfully" part in "(almost) successfully" refers to the ZRTP encryption which is reported by both SC and Twinkle to go fine (Twinkle shows "SAS confirmed"); this works also in case of later ZRTP activation during the call by the SC peer when starting the call unsecured

- for building Twinkle with ZRTP I didn't use version 0.9 of libzrtpcpp linked on the Twinkle page; instead I've used the latest version I found at ftp://ftp.gnu.org/gnu/ccrtp/ this being 1.3.0; there were some minor problems at building Twinkle in relation with this version of libzrtpcpp, which after some search I found to be partly reported here also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479874 and I solved them pretty similar with the changes present in the patch at that address; this was the only modification I've done to the sources during Twinkle setup

These are the main test and test setup details for now. Like I said above I'll try also a Twinkle-SC test in registrar mode and after this I'll go back a bit to the no-registrar patch I've adapted, to try figure out the solution for the registrar mode issues it has ( only hope it's not very SIP related, as protocol matters, because I'm far from being an expert in it :slight_smile: ).
If you have other test configuration ideas for the SC's ZRTP integration (I'm going to think on this too) please don't hesitate to tell me. For the current phase, until the next test at least :), seems to be stable.

Regards,
Emanuel

···

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Emanuel,

you probably used an older version of twinkle that is not yet
adapted to user libzrtpcpp 1.3.0. This version of libzrtpcpp
if required because it implements the latest version of ZRTP.

Michel de Boer (author of twinkle) is just working on this - but
I can send you the patches to make it work. Just drop me a line. The
patch at Debian is not complete/correct as far as I can see.

If you have any problems when using GNU ZRTP (also building/linking)
just give a trigger and I try to figure out what's wrong.

Thanks,
Werner

Onica S. Emanuel schrieb:

···

Hello Romain, Werner,

I finally managed to make a basic setup of a Linux partition (sorry for the bit of delay on that but the boot loader somehow managed to mess up my MBR and had to do some partition recovery). Anyway, the main idea after all is that I installed Twinkle - the 1.2 version from the site, and (almost) successfully ran the first ZRTP Twinkle-SC secured call.

Now, some details about the testing:

- SC is running on WinXP SP2 (MCE) and Twinkle on openSUSE 11 ( so it's a bit of interplatform communication testing also I guess :slight_smile: )

- the test was done using no-registrar mode using the patch I adapted for SC in its latest form (for which I must take some time to try and see if I can fix it to allow registrar mode also, because like I said in the last mails it still doesn't)

- the "(almost)" part in "(almost) successfully" above refers to the fact that the audio stream sent by SC - received by Twinkle is very garbled and inconsistent (can't distinguish any word communicated through it) but I think it's a codec related problem, because this happens also in unencrypted communication; I'll try a test also using registrar mode to see how it goes on, but I really don't think this has anything to do with the problem

- the "successfully" part in "(almost) successfully" refers to the ZRTP encryption which is reported by both SC and Twinkle to go fine (Twinkle shows "SAS confirmed"); this works also in case of later ZRTP activation during the call by the SC peer when starting the call unsecured

- for building Twinkle with ZRTP I didn't use version 0.9 of libzrtpcpp linked on the Twinkle page; instead I've used the latest version I found at ftp://ftp.gnu.org/gnu/ccrtp/ this being 1.3.0; there were some minor problems at building Twinkle in relation with this version of libzrtpcpp, which after some search I found to be partly reported here also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479874 and I solved them pretty similar with the changes present in the patch at that address; this was the only modification I've done to the sources during Twinkle setup

These are the main test and test setup details for now. Like I said above I'll try also a Twinkle-SC test in registrar mode and after this I'll go back a bit to the no-registrar patch I've adapted, to try figure out the solution for the registrar mode issues it has ( only hope it's not very SIP related, as protocol matters, because I'm far from being an expert in it :slight_smile: ).
If you have other test configuration ideas for the SC's ZRTP integration (I'm going to think on this too) please don't hesitate to tell me. For the current phase, until the next test at least :), seems to be stable.

Regards,
Emanuel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Emanuel,

Anyway, the main idea after all is that I installed Twinkle - the 1.2 version from the site, and (almost) successfully ran the first ZRTP Twinkle-SC secured call.

That's great news! Congratulations!

These are the main test and test setup details for now. Like I said above I'll try also a Twinkle-SC test in registrar mode and after this I'll go back a bit to the no-registrar patch I've adapted, to try figure out the solution for the registrar mode issues it has ( only hope it's not very SIP related, as protocol matters, because I'm far from being an expert in it :slight_smile: ).

In any case I think it is also good to test with a registrar, to ensure that everything is fine with or without it.

If you have other test configuration ideas for the SC's ZRTP integration (I'm going to think on this too) please don't hesitate to tell me. For the current phase, until the next test at least :), seems to be stable.

It would be interesting to test with other clients that supports ZRTP (Zfone?).
Also, if you have interest in writing JUnit tests for your code, that could be a good way to ensure no regressions are made during further developments:
http://www.sip-communicator.org/index.php/Documentation/DesignOfTheJUnitTests

Cheers,

···

On 2008/07/11, at 0:48, Onica S. Emanuel wrote:
--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
LSIIT - Networks and Protocols Team
http://clarinet.u-strasbg.fr/~kuntz/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net