Add support for ZRTP

[GoogleCodeExporter]

Not a bug - enhancement 

please add ZRTP support this allows for a more secure handling of handset to 
handset key exchanges.   Two linux softphones I know of built on pjsip allow 
SRTP and ZRTP, allow using them at the same time.

other pjsip implementations:
http://www.sflphone.org/
http://twinklephone.com/

Original issue reported on code.google.com by wheresau...@lavabit.com on 5 Oct 2010 at 10:52

[GoogleCodeExporter]

Werner will correct me if I mistake, but my understand is the following :

ZRTP is somehow always optional cause it is based on RTP and send on RTP some 
hello to see if other part does accept that.

SRTP mechanism is different. There is mandatory SDP infos about the fact the 
call will be done using SRTP, while using ZRTP it's not mandatory.

I think that besides, when you use ZRTP process is not the same. You can just 
not talk at all if you see that the communication is being encrypted. I'm 
adding the little icon to inform that the call is encrypted, but if you don't 
get the popup it is a good indication about that already ;). 

I think that the ZRTP options would more be something like 'Disabled', 
'Optional', 'Only if remote announced in SDP'. 
Cause 'mandatory' make not really sense cause there is always the beginning of 
the communication where the SAS has to be acknowledged when the call is done 
without ZRTP encryption. 
The only way to provide mandatory would be to say : "mandatory for incoming 
only" and would also mean that remote side has to announce in SDP ZRTP support. 
Or we could cut the communication if ZRTP negociation fails... but since the 
user should be aware about that (my bad, not yet ;) ), not really hurting to 
leave user decide.

Original comment by r3gis...@gmail.com on 7 May 2011 at 3:29

[GoogleCodeExporter]

Hi regis,

i can't see the security settings under network any more. Did you change 
something? Are they gone, or is it just on my device (defy) for some reason?

Original comment by nilsjan...@gmail.com on 7 May 2011 at 7:37

[GoogleCodeExporter]

If you sure that you are using a tls version, the other reason for not having 
the setting is that the sip stack has never been started. 
The setting only appear if pjsip has been loaded once to be able to know 
whether it has been built with tls support.
So you should first try to register and then go in settings.

Original comment by r3gis...@gmail.com on 7 May 2011 at 9:37

[GoogleCodeExporter]

ZRTP on r836 nightly works brilliantly for me now! Thanks for fixing whatever 
bug there was. I'm running it on LeeDroid Gingerbread Rom V 3.0.6 (HTC Desire). 
You guys rock!

Original comment by chhab...@gmail.com on 8 May 2011 at 11:25

[GoogleCodeExporter]

sorry, i used the usual nightlies...

Original comment by nilsjan...@gmail.com on 8 May 2011 at 11:36

[GoogleCodeExporter]

@regis (51):
Regis is right. Othe client that support ZRTP just have an enable check box. If
checked then ZRTP tries to negotiate the security data with the other client. If
the othe client also support ZRTP - bingo, secure connection will be 
established. If
the other partner does not support ZRTP then the ZRTP implementation switches to
listening" mode to see if the other partner sends a ZRTP Hello to announce that 
it
is willing to negotiate SRTP keys.

You may announce in the SDP that your client supports ZRTP (I need to look if 
this
is avaiable for pjsip). However, some operators/ISPs/SIP providers block SIP 
INVITE
if they see an unknown SDP header or they block SIP INVITE if the SDP is not 
what
they like :-) . 

Best regards,
Werner

Original comment by werner...@googlemail.com on 9 May 2011 at 6:53

[GoogleCodeExporter]

Just a remark to Regis and other that like to build CSipSimple from scratch
or like to use pjsip (pjsua infact) together with ZRTP:
Unfortunatly Benny (the mainatiner of Pjsip) did not include an important 
feature
in the latest release of pjsip (even it was announce for this release). When you
like to use ZRTP together with PJSUA you must apply a patch (it's a small patch)
that allows an application to enable the ZRTP transport in pjsip/pjsua.

Best regards,
Werner

Original comment by werner...@googlemail.com on 9 May 2011 at 6:58

[GoogleCodeExporter]

Great stuff, just tested on two csipsimple devices attached via freeswitch zrtp 
pop ups are working! thanks r3gis and werner for all the hard work!

had to enable proxy media
http://wiki.freeswitch.org/wiki/Proxy_Media

Original comment by wheresau...@lavabit.com on 9 May 2011 at 11:38

[GoogleCodeExporter]

regis, when do you think will this get into the stable version? and what is the 
seperate tls version for? 

Original comment by nilsjan...@gmail.com on 12 May 2011 at 3:13

[GoogleCodeExporter]

It will be included in stable version as soon as I introduce the way to 
download separately a .so lib (or as a third party application). It's not 
included in normal version cause TLS build include lib openssl (cause that's 
not in android NDK), and it make the size of the app twice bigger.
My goal is to have it as a "module" of the app. 
It could be either by downloading directly the .so file, but after thinking a 
lot about that I think that a better idea would be another app that bring the 
relevant .so files.
I'll have the same problem for the video (that should also be distributed as a 
plugin).
The way it's managed for themes apps is not so bad I think (with a link in the 
app to find Themes and Plugins).

For now the only thing I'd have to solve conceptually with this approach is the 
way to update things (should not be so difficult) and second point the way 
several plugins could work together (probably some plugins such as TLS that 
requires to rebuild the entire stack may not be considered as plugin but as 
"core" and would not be compatible with other "cores".

Then I'll start to make a proof of concept of this "modular" approach and 
include it in future versions. 

A could thing would have been to have pjsip really modular regarding TLS but 
AFAICT it's not currently easy to do.

Original comment by r3gis...@gmail.com on 12 May 2011 at 4:49

[GoogleCodeExporter]

that sounds good. perhaps link to the tls version from 
http://code.google.com/p/csipsimple ?

best,

nils

Original comment by nilsjan...@gmail.com on 13 May 2011 at 7:06

[GoogleCodeExporter]

@werner, do you know the min. cpu power needed for zrtp on android?

Original comment by nilsjan...@gmail.com on 13 May 2011 at 7:11

[GoogleCodeExporter]

did anybody try it via gprs/edge/umts? 

for me it currently only works via wifi, but that could be the fault of my 
mobile provider blocking sip...

Original comment by nilsjan...@gmail.com on 24 May 2011 at 2:01

[GoogleCodeExporter]

yes, the key exchange does not seem to be happening over 3G but works great 
over wifi!  3G still connects the call with no SAS(zrtp exchange) message.  
r3gis think this could be application somewhere?

Original comment by wheresau...@lavabit.com on 24 May 2011 at 9:17

[GoogleCodeExporter]

Issue 1153 has been merged into this issue.

Original comment by r3gis...@gmail.com on 15 Jul 2011 at 2:25

[GoogleCodeExporter]

Issue 1152 has been merged into this issue.

Original comment by r3gis...@gmail.com on 15 Jul 2011 at 2:26

[GoogleCodeExporter]

@issue 1152:

After ZRTP exchanged keys with both sides it starts the secure connections 
(SRTP)
immediately. The SAS confirmations is independent of this - one may chosse never
to verify and confirm SAS with the other side. In such a case I strongly 
recommend
to check the SAS with the other side verbally. Once this was done and was ok 
you 
may click SAS verify and ZRTP implementation remembers this and can perform
additional checks on the next key exhanges and issues warnings if it detects
something is wrong. If SAS was verfied and ZRTP does not reports any warning 
during
the next key exchanges then no Man-in-the Middle occured and security is ok.

Original comment by werner...@googlemail.com on 17 Jul 2011 at 12:35

[GoogleCodeExporter]

@comment 62:

Sorry no. What I did to reduce CPU consumption was: enable elliptic curve 
Diffie-Helman public key exchange as default. This requires much less CPU power
than finite-fiel DH while more secure (win-win, isn't it :-) )

@comment 63 and 64

Sometimes 3G operators filter RTP packets that are not _real_ RTP. ZRTP uses the
RTP connection to exchange data and use a RTP format, but these are not _real_
RTP packets. To check this someone should use Wireshark to analyse the real
data traffic and check whether or not ZRTP packets make their way thru 3G 
connections.

I cannot check 3G because I don't own an Android device. 

Just a note here:
in comment 64 I read: ...still connects the call with no SAS message... . As 
said,
I can't give a response here how CSipSimple implemented the GUI for ZRTP. Other 
clients that support ZRTP usually display a small textfield that contains the 
4-char
SAS and a check-box to "verify" the SAS with ZRTP (see comment 67). A client
may also show which crypto algorithms are active in SRTP. The SAS shall be 
shown as
soons as secure call was established (ZRTP uses a callback to inform the GUI).

Original comment by werner...@googlemail.com on 17 Jul 2011 at 12:47

[GoogleCodeExporter]

About last point, I did a very recent change to improve this point. It's still 
not yet perfect and I'll try to add your advise on issue 1153 to improve how 
it's integrated.

For reference, what is expected now is :
when call is secured it show "ZRTP : SAS" with a little icon on the top right 
of the call card. If SAS has to be verified, it shows an alert that one can 
accept to verify it (previously it was asking each time - now it does only if 
it has actually to be verified).
Except from pure UI issues, there is also still something I have to solve on my 
side. That's more complicated to manage and should allow multiple calls with 
ZRTP. (It's about the way the UI store the reference to the zrtp transport... 
that's not so easy to manage with JNI on the middle ;) ).

Original comment by r3gis...@gmail.com on 17 Jul 2011 at 4:01

[GoogleCodeExporter]

can you please list the ZRTP-enabled SIP servers that you were able to use to 
establish a ZRTP connection successfully between two CSipSimple clients?

When switched "Create ZRTP" On (and SRTP off, or any other choice), the call is 
started and ended immediately on 2 of the servers I checked (Kamailio and 
FreeSWITCH).

Thanks!

Original comment by a...@privatemail.lv on 1 Aug 2011 at 5:21

[GoogleCodeExporter]

There are no specific SIP servers that handle ZRTP because this is not 
required. ZRTP
is a protocol that negotiates the keys that are required to setup a SRTP 
context and
does this via the RTP session (usually the audio connection). Thus no SIP 
involved.
ZRTP starts it's negotiation as soon as the first media session is ready.

ZRTP uses it's own underlying SRTP - thus if you like to use ZRTP please switch 
off
the other SRTP which uses a  specific SIP mechanism to exchange the SRTP keys. 

When I test ZRTP I use kamaillio (openSER) as SIP proxy and registrar and it 
works 
quite well. Which problems do you see? Any logs from kamaillio?

Original comment by werner...@googlemail.com on 1 Aug 2011 at 9:20

[GoogleCodeExporter]

Apologies for the slightly off-topic question....

Does anyone know of a termination provider that offer ZRTP support?
(For the specific threat model, it's enough we encrypt until the service 
provider {assuming it's not in a particular country} and make simple 
unencrypted PSTN calls onward).
This would be also used for conferencing a number of ZRTP supported clients 
within the problematic country.

Naturally, we can setup our own server for that - but there are benefits for 
using an existing service provider.

Thanks,

Yahel.

Original comment by ya...@airjaldi.org on 10 Aug 2011 at 6:59

[GoogleCodeExporter]

I'm not aware of any termination provider that connects VoIP to PSTN that also
supports ZRTP. AFAIK this requires a Asterisk server with ZRTP enhancement and 
you
need to have a ZRTP implementation that support a specific ZRTP feature: trusted
Man-in-the-Middle. Currentliy the PJSIP implementation (CSipSimple uses this
implementation) does not support this feature because it is considered a 
security
risk.

Just send me a PM if you need some more support and/or discuss specific 
features.

Regards,
Werner

Original comment by werner...@googlemail.com on 10 Aug 2011 at 1:21

[GoogleCodeExporter]

Hello guys.I am really excited about ZRTP support in CSipSimple. I have a 
problem and mostly I think is a GUI one.
    I am testing ZRTP in CSipSimple with a HTC Desire HD (Android 2.3.3) and 2 Samsung Galaxy Mini (Android 2.2.1) clients connected to a Freeswitch server (which runs in proxy media mode). 
    The problem is that I only sometimes see the 4 digit SAS displayed on both phones,sometimes the SAS appears only on one phone but most often it is not displayed at all on any phone, although ZRTP is active (I know that because I registered on the Freeswitch server with a client on the phone and a client on a computer (Jitsi-former SIP Communicator) and in Jitsi it showed me that ZRTP is active, but on the phone it didn't display the 4 digit SAS or that ZRTP was active).
 The catch is that if I select "Disconect" from the app menu, and I restart the app again (on both phones) then, on the first call made after that the SAS is displayed on both phones, but on the other calls it is just like I've mentioned before.
  So, even if ZRTP is active, the user won't know that because it isn't displayed anywhere and he can't verify the SAS with the other party. 
Please check this problem, and I will continue to test the app and post 
updates. 
 Keep up the good work.

Original comment by ursu.adr...@gmail.com on 24 Oct 2011 at 10:21

[GoogleCodeExporter]

Regarding @74

I cannot really test this because I don't have a freeswitch setup. Thus just a 
question: do you use anything like the "PBX ZRTP registration" feature in 
freeswitch? I know that freeswitch support this sort of trusted 
Man-in-the-Middle feature?

If it is really purly "proxy-media" I would be interessted in some network 
traces between both clients and the freeswitch. 

Best regards,
Werner

Original comment by werner...@googlemail.com on 6 Nov 2011 at 11:27

[GoogleCodeExporter]

I play with r1064 and ZRTP. My experience is:

The ZRTP SAS only show at the first call, because the implementation is not 
complete, see that 
http://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/src/com/csips
imple/pjsip/UAStateReceiver.java?r=1060#458
"// For now, just get the first one..." is the problem. Another problem that 
the transport_zrtp.c is often crash with sigsegv.

********** Crash dump: **********
Build fingerprint: 
'samsung/GT-S5570/GT-S5570:2.3.4/GINGERBREAD/XXKPK:user/release-keys'
pid: 1359, tid: 1411  >>> com.csipsimple:sipStack <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 07000004
Stack frame #00  pc 0010b260  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine pj_lock_acquire in 
apps/pjsip/project/build/..//pjlib/build/..//src/pj/lock.c:178
Stack frame #01  pc 0010c672  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine lock_timer_heap in 
apps/pjsip/project/build/..//pjlib/build/..//src/pj/timer.c:104
Stack frame #02  pc 00151ebe  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine timer_add_entry in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/trans
port_zrtp.c:303
Stack frame #03  pc 00152504  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine activateTimer in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZrtpCallbackWrapper.cpp:42
Stack frame #04  pc 00153018  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine activateTimer in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZRtp.cpp:2126
Stack frame #05  pc 00158f9e  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine startTimer in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZrtpStateClass.cpp:1352
Stack frame #06  pc 00159c90  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine evInitial in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/inclu
de/libzrtpcpp/ZrtpStates.h:76
Stack frame #07  pc 00159dd8  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine processEvent in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZrtpStateClass.cpp:129
Stack frame #08  pc 0015352c  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine startZrtpEngine in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZRtp.cpp:199
Stack frame #09  pc 001513aa  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine zrtp_startZrtpEngine in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/zrtp/
ZrtpCWrapper.cpp:122
Stack frame #10  pc 00151c90  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine pjmedia_transport_zrtp_startZrtp in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/trans
port_zrtp.c:754
Stack frame #11  pc 00152082  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine transport_send_rtp in 
apps/pjsip/project/build/..//third_party/build/zrtp4pj/../../zrtp4pj/zsrtp/../..
/../pjlib/include/pj/string.h:634
Stack frame #12  pc 000e49c0  /data/data/com.csipsimple/lib/libpjsipjni.so: 
Routine pjmedia_transport_send_rtp in 
apps/pjsip/project/build/..//pjmedia/build/..//src/pjmedia/stream.c:1345
S

this is because the timer_pool did not freed at transport_destroy(), but the 
pjlib destroys it automatically at end of first call (pool_caching.c:108), so 
when the next call started the timer_pool is already destoyed and the sigsegv 
occurs. The problem maybe that the timer_stop() function is not used, so the 
implementation is not complete also.

Furthermore the timer_android.cpp is unstable, with that the SIP stack always 
sent a REGISTER message to the SIP server at every 1-3 seconds. I dont know why 
and I don't know that this is related to ZRTP or not. When I build the library 
with the original timer.c this problem is gone, but CSipSimple does not accept 
incoming calls when device is in idle.

Original comment by gcjo...@gmail.com on 7 Nov 2011 at 3:41

[GoogleCodeExporter]

About timer_android.cpp, you're right for TLS version. 
ZRTP and TLS builds are broken til the next stable release (which will come 
really soon). If I want to have something stable without regression risk on 
trunk with android 1.6 I've to break ZRTP support for a while.

I've something working again but based on pjsip-2.0. 
So for now hold for a couple of week if you need ZRTP (or try to build with the 
new jni folder ;) ).

About the fact it take only the first SAS, good point, I forgot that I 
postponed this implementation :). So to be done :)

Original comment by r3gis...@gmail.com on 7 Nov 2011 at 3:58

[GoogleCodeExporter]

Oh, and I forgot to add that with the pjsip-2.0 builds (after the next stable 
release on the android market), ZRTP and TLS will be on of stock features of 
csipsimple :). 

I finally found a fancy way to use openssl if available on the platform (99.99% 
of cases) and to load it dynamically else. (Many other native features will 
becomes available through plugins too : codecs, audio and video device 
implementations etc).

Original comment by r3gis...@gmail.com on 7 Nov 2011 at 4:04

[GoogleCodeExporter]

Thank you! If the new trunk with ZRTP will be buildable, I will test it! :)

Original comment by gcjo...@gmail.com on 7 Nov 2011 at 5:44

[GoogleCodeExporter]

@r3gis.3R@gmail.com

can u give a hint on how to fix that ZRTP SAS issue so the SAS always shows up?

also, if i build with the new jni folder, will ZRTP work ? :p

keep on up with the great work!

cheers,
Francisco

Original comment by francisc...@gmail.com on 7 Nov 2011 at 6:16

[GoogleCodeExporter]

@fransisco : I just did a commit that should help (even if not yet clean) with 
the sas display as pointed out by gcjoe. If you use timer.c implementation 
instead of android_timer.cpp implementation it should work. It may also work 
depending on device with the timer_android.cpp (depends on the dalvik config).

About the other issue pointed out by gcjoe : timer_stop never called there is 
maybe something too. I've to investigate this point too when pjsip-2.0 will be 
used on nightlies. 
Maybe if Werner can give me some pointers about why timer_stop exists but is 
never launched by the rest of the code, it could help me to understand what is 
wrong in my timer implementation or if there is something missing somewhere ;).

Original comment by r3gis...@gmail.com on 7 Nov 2011 at 9:22

[GoogleCodeExporter]

 First of all, thanks r3gis for the modification to the source code about SAS display . It works great. I have a question. I am getting this error in LogCat: 
11-10 11:49:32.827: E/libpjsip(21359):  11:49:32.843 timer_android.  Huh, pj is 
cancelling something already unknown... : 0. 

What does this mean? I understand that there is a problem with the timer. What 
can I do to fix this? Does this influence ZRTP in any way? I mean, ZRTP is 
active and my call is secure, isn't it? 

Also I would like to suggest an enhancement which already exists in Jitsi. 
There, in Options->Zrtp (ZRTP Ninja) you can select in Standard and Mandatory  
different key lengths for AES encryption (128 and 256) , and during a call it 
is displayed on the screen that your call is secured , the encryption method 
and key length. For example: (Cipher: AES-256). Do you think this could be 
implemented in CSipSimple also under the 4 digit SAS ?

Thanks, and keep up the good work.

I am using CSipSimple r1064 on a Htc Desire HD (Android 2.3.3) and Samsung 
S5570 (Galaxy Mini Android 2.2.1) on a Freeswitch Server in proxy media mode. 

Original comment by ursu.adr...@gmail.com on 10 Nov 2011 at 10:09

[GoogleCodeExporter]

The error raised by the timer_android implementation should actually be a 
warning. It is just to warn me about the fact pjsip is trying to cancel a timer 
that it has already previously cancelled or that was already fired. I tried to 
track down which was the root cause of this dupplicate cancel. But seems to be 
normal, and the timer implementation should (and actually is), robust to 
duplicate cancel or cancel after execution of the callback. So this error 
should just be ignored ;). That was just for me to debug that.

About the key lenght, it should be possible I think. I put that in my todo list 
:).

Original comment by r3gis...@gmail.com on 10 Nov 2011 at 10:14

[GoogleCodeExporter]

New nightly build available here :
http://nightlies.csipsimple.com/trunk/

Now TLS and ZRTP are part of trunk builds. ZRTP support should have been really 
improved. The UI should not mix infos from several calls anymore and should 
always display the SAS (it asks to confirm only if needed). It will also show 
the AES encryption type.

As it's a new build toolchain and it's based on a different pjsip version there 
is maybe some possible regression, feel free to open new issues about it :). 
Also I'm unsure about how it will go on all android phones since the openssl 
library is not included into the app but it tries to rely on the one of the 
phone. 
For now I never found a phone without openssl on it. However, if someone has a 
phone without openssl I can produce a plugin which intent to provide openssl 
library to CSipSimple.  

Original comment by r3gis...@gmail.com on 20 Nov 2011 at 9:42

[GoogleCodeExporter]

Thank you! My first try with your binary package (r1129) is no luck, beacause 
CSipSimple crashes immediately when the peer answer the call (TLS+ZRTP enabled 
of course). I'll try build one from source (if I can) in the next week, then I 
can send a backtrace.

Original comment by gcjo...@gmail.com on 20 Nov 2011 at 6:32

[GoogleCodeExporter]

Thanks r3gis, my first wave of testing on r1132 did not go so well.  The 
calling phone would freeze when placing a call to a zrtp enabled peer.  
Happened on both my devices. r1136 works great!  Tested a few calls between 
espresso devices running cyanogen 7.1.  ZRTP support has come so far in the 
last year, thanks!!  I did all my testing on tanstagi.net, its been 
around/stable for a year as well, with more and more people using it, any 
chance for a wizard with TLS/ZRTP enabled?  It requires no special 
configuration options just tls/zrtp. 

Original comment by wheresau...@lavabit.com on 21 Nov 2011 at 2:20

[GoogleCodeExporter]

In 1136 I did a couple of fixes specially for android 2.2 device (that were 
completly broken previously).

Yes we should add a Tanstagi.net wizard now that ZRTP and TLS are features of 
the trunk version :D. I've just added an issue about that : issue 1389.
In a first time maybe some simple link to the web page to create an account. If 
you think it would be better to do that through a more advanced web api from 
within the app you can send me infos by mail or on the issue 1389.

Original comment by r3gis...@gmail.com on 21 Nov 2011 at 2:46

[GoogleCodeExporter]

Sorry but 1136 is still crash for me when the peer answer the call (ZRTP mode).

********** Crash dump: **********
Build fingerprint: 
'samsung/GT-S5570/GT-S5570:2.3.4/GINGERBREAD/XXKPK:user/release-keys'
pid: 1895, tid: 2208  >>> com.csipsimple:sipStack <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 3135327c
Stack frame #00  pc 000e9874  /mnt/asec/com.csipsimple-1/lib/libpjsipjni.so: 
Routine pj_lock_acquire in 
CSipSimple/jni//pjsip/android_toolchain/pjlib/../../sources/pjlib//src/pj/lock.c
:178
Stack frame #01  pc 000ebbea  /mnt/asec/com.csipsimple-1/lib/libpjsipjni.so: 
Routine lock_timer_heap in 
CSipSimple/jni//pjsip/android_toolchain/pjlib/../../sources/pjlib//../../android
_sources/pjlib/src/timer_android.c:338
Stack frame #02  pc 0007a5a0  /mnt/asec/com.csipsimple-1/lib/libpjsipjni.so: 
Routine Java_org_pjsip_pjsua_pjsuaJNI_pj_1timer_1fire in 
CSipSimple/jni//swig-glue/android_toolchain/../nativesrc/pjsua_wrap.cpp:18713
Stack frame #03  pc 000180f4  /system/lib/libdvm.so
Stack frame #04  pc 00046624  /system/lib/libdvm.so
Stack frame #05  pc 0001d304  /system/lib/libdvm.so

Original comment by gcjo...@gmail.com on 21 Nov 2011 at 11:10

[GoogleCodeExporter]

Another problem that r1128 - r1136 versions are never sent REGISTER message to 
the SIP server while the account status shown as "Registered" (green).

Original comment by gcjo...@gmail.com on 21 Nov 2011 at 11:15

[GoogleCodeExporter]

a current walk through for using csipsimple w/ tanstagi 
http://freeborn.devio.us/doku.php?id=androiddiffemyhellman 

gcjo, did you make sure to enable TLS in the transport settings of your account 
settings?

Original comment by wheresau...@lavabit.com on 22 Nov 2011 at 9:01

[GoogleCodeExporter]

Thank you for this pointer! Both problems are solved!

No I don't use TLS. I try to use CSipSimple with my own Freeswitch build 
(simple bypass mode). This is a working setup, the ZRTP calls are works fine 
when I try with an r1064 build.

But my config was wrong, because under Network->Secure transport it was checked 
on the TLS checkbox. After I uncheck this box, now the outgoing calls are works 
fine with ZRTP (on UDP transport), so in this case no timer crash anymore!

The REGISTER message problem is also solved. I forgot to fill the "Registration 
URI" (it was empty) in the account settings and this caused that the account 
shown as "Registered" (green) but the REGISTER message was not sent.

Thank you!

Original comment by gcjo...@gmail.com on 22 Nov 2011 at 11:32

[GoogleCodeExporter]

Thanks for the Link!
Is this kinda common description for setting up an account for crypted use?
The reason why I am asking: i am new to this and i dont want to open tickets 
because of misconfigured devices on my side:).
It would be great if we have smth like an easy to follow walkthrough for the 
common settings.

Why do you guys use TLS if SRTP does the work already?
Btw.. i tried to get some SAS working, but it didnt show up. Therefore ZRTP 
tells us: "No verification"

Thanks for you comments

Original comment by automate...@gmail.com on 25 Nov 2011 at 5:14

[GoogleCodeExporter]

Well, first thing to know is that there is to communication plan in SIP. There 
is the media plan (the actual audio other side receive) and the control plan 
(it's here to invite, hold, cancel, hangup the call).
SRTP and ZRTP apply both to media plan. TLS (SIPS) apply to control plan. 
If there is a hacker on your network and that the control plan is not secured 
he will be able to see who calls who and to terminate calls (and maybe to 
gather some interesting infos about your sip password -- not immediate info, 
but could be deduced after many calls).
If the media plan is not secured, he will be able to listen what is said in the 
conversation.
So TLS and S/Z RTP are for two distinguished purpose.

There's guys here much more expert about these points than me so do not 
hesitate to correct me if I'm wrong ;).

For TLS you need a sip server that supports TLS to be able to talk with it an 
encrypted way. So this is a feature of your sip provider. 

About SRTP and ZRTP that's different.
First about SRTP. This way has to be announced during the negociation of call 
and to be accepted by both parts. If the media does not go directly between you 
and your remote party but is modified by your sip provider they also need to 
support SRTP on their side. Then on between their server and your remote party 
it's another negociation.
So in order to have this feature working, either your sip provider (if media 
gatewway) or your remote party must support this, else it will not be activated.
About ZRTP. It is not 'necessary' to announce it during the negociation, and 
can be established over an ongoing call. As previously both party *must* 
support the feature. If your sip provider filter or does media gateway stuff it 
may drop ZRTP feature so that the other side will never receive ZRTP hello 
packets. 

So also, to have this feature working you may first understand what's done on 
your sip server side.

If you just want to directly test the feature without further configuration on 
a sip server, there is a simple way to do so if your two devices are on the 
same network. 
You can simply create a "local account" on each device (there is a specific 
wizard for that). Disable all other accounts on each device. And call directly 
one device with the other using direct IP address (you can get in android 
settings). To do this peer to peer call, use the text dialer (little icon on 
the left top corner of the dialer). And type the complete remote address : 
user2@xxx.xxx.xxx.xxx where the xxx.xxx.xxx.xxx is the ip address of the second 
device.

Original comment by r3gis...@gmail.com on 25 Nov 2011 at 6:06

[GoogleCodeExporter]

The above timer crash (comment c88) is still occurs but very rarely.

Original comment by gcjo...@gmail.com on 27 Nov 2011 at 10:47

[GoogleCodeExporter]

automate...

yes thats a guide to get csipsimple running quickly with TLS and ZRTP on 
tanstagi.  Its even easier now that r3gis has added the wizard.  Good luck, let 
me know if you have any issues connecting.

Original comment by wheresau...@lavabit.com on 30 Nov 2011 at 2:57

[GoogleCodeExporter]

I was just passed this pdf (pdf: 
http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper001.pdf ) it states 
that VBR codecs can be snooped on regardless of encryption.  Im trying to find 
out which codecs are VBR and which are non-vbr, anyone else have any thoughts 
on this?

Original comment by wheresau...@lavabit.com on 30 Nov 2011 at 3:04

[GoogleCodeExporter]

has someone managed to get CSipSimple working with linphone?
srtp works, but with zrtp, sound is garbled (using the same codecs as with 
srtp).
OnSIP and IpTel seem to work the best, Nymgo seems to hijack the stream and 
disable ZRTP, Ekiga seems not very reliable or is too picky.

message: ZRTP INFO zrtp_InfoInitConf1Received
message: ZRTP secrets on: SAS is abcd previously verified no - algo 
AES-CM-128/DH3k
message: sent ZRTP Confirm2 31337
message: ZRTP secrets for receiver are ready
message: Authentication token is abcd (unverified)
message: received ZRTP Confirm1 10
message: ZRTP secrets for sender are ready
message: ZRTP INFO zrtp_InfoSecureStateOn
message: Audio stream is encrypted 
message: All streams are encrypted
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
message: bandwidth usage: audio=[d=68.5,u=80.4] video=[d=0.0,u=0.0] kbit/sec
message: Thread processing load: audio=2.180420 video=0.000000
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
message: received ZRTP Conf2ACK 11
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
...a million of these...
warning: srtp_unprotect failed; packet may be plain RTP
warning: srtp_unprotect failed; packet may be plain RTP
error: srtp_unprotect failed 7 ; packet discarded (may be plain RTCP)

... BYE ...

message: cb_sndbye (id=17)
message: eXosip: timer sec:0 usec:509995!
message: oRTP-stats:
   Audio session's RTP statistics :
message:  number of rtp packet sent=1782
message:  number of rtp bytes sent=306504 bytes
message:  number of rtp packet received=1750
message:  number of rtp bytes received=306436 bytes
message:  number of incoming rtp bytes successfully delivered to the 
application=305216 
message:  number of rtp packet lost=32
message:  number of rtp packets received too late=3
message:  number of bad formatted rtp packets=0
message:  number of packet discarded because of queue overflow=0
message: ms_filter_unlink: MSAlsaRead:0x2153ac0,0-->MSVolume:0x2171a00,0
message: ms_filter_unlink: MSVolume:0x2171a00,0-->MSG722Enc:0x215f240,0
message: ms_filter_unlink: MSG722Enc:0x215f240,0-->MSRtpSend:0x2102d80,0
message: ms_filter_unlink: MSRtpRecv:0x215de70,0-->MSG722Dec:0x214cc90,0
message: ms_filter_unlink: MSG722Dec:0x214cc90,0-->MSDtmfGen:0x215e060,0
message: ms_filter_unlink: MSDtmfGen:0x215e060,0-->MSVolume:0x20b20f0,0
message: ms_filter_unlink: MSVolume:0x20b20f0,0-->MSEqualizer:0x215f4f0,0
message: ms_filter_unlink: MSEqualizer:0x215f4f0,0-->MSAlsaWrite:0x215f140,0
message: Stopping ZRTP context
message: ZRTP secrets off
message: ZRTP secrets off
message: ZRTP INFO zrtp_InfoSecureStateOff
message: Destroying ZRTP wrapper
message: Destroying ORTP-ZRTP mutex
message: Destroying SRTP contexts
message: ORTP-ZRTP context destroyed
message: Audio MSTicker thread exiting
message: Filter usage statistics:
message: Name   Count   Time/tick (ms)  CPU Usage
message: MSAlsaWrite 1743 0.191468 41.5972
message: MSAlsaRead 3569 0.0834608 37.117
message: MSG722Dec 1743 0.0316154 6.86858
message: MSG722Enc 1673 0.0252301 5.26134
message: MSRtpRecv 3570 0.00999456 4.44606
message: MSRtpSend 3569 0.00943405 4.19555
message: MSVolume 3416 0.00094114 0.40061
message: MSDtmfGen 3570 0.000193293 0.0859863
message: MSEqualizer 1743 0.000127403 0.0276788
message: MSFilePlayer 0 0 0
message: MSSpeexEC 0 0 0
message: Call 0x215e3f0: moving from state LinphoneCallStreamsRunning to 
LinphoneCallEnd
message: Resetting the current call

Original comment by hvtaifwk...@gmail.com on 4 Mar 2013 at 8:06

[GoogleCodeExporter]

sflphone kind of works, after fixing a bug in it, but:

A ZRTP error forced the call with asdjweklfkwejrj@getonsip.com to fall under 
unencrypted mode.
Exact reason: DH Error: bad pvi or pvr ( == 1, 0, or p-1)

Original comment by hvtaifwk...@gmail.com on 4 Mar 2013 at 10:02

[GoogleCodeExporter]

with latest git libzrtpcpp and ortp:
linphone 3.5.2 works with zrtp without extra patches, ortp needed one patch:
-               zrtp_processZrtpMessage(zrtpContext, ext_header, peerssrc);
+               zrtp_processZrtpMessage(zrtpContext, ext_header, peerssrc, 
zrtp_total_packet_length);

Original comment by hvtaifwk...@gmail.com on 5 Mar 2013 at 10:48

[GoogleCodeExporter]

When calling CS→Linphone, ZRTP does not get enabled.  It works the other way.

CS→Linphone logs as seen from CS:
08:59:16.802 zrtp_android.c  ZRTP info message: Responder: Commit received, 
preparing DHPart1
08:59:16.802 zrtp_android.c  ZRTP info message: DH1Part: Generated a public DH 
key
08:59:17.070  strm0x15a169c  RTP decode error: Invalid RTP version 
(PJMEDIA_RTP_EINVER) [err:220122]
08:59:17.070  strm0x15a169c  RTP status: badpt=0, badssrc=0, dup=0, 
outorder=-1, probation=0, restart=0
08:59:17.106 sip_endpoint.c  Processing incoming message: Response msg 
200/INVITE/cseq=13425 (rdata0x134e42c)
...
08:59:17.151  pjsua_media.c  .....Call 0: updating media..
08:59:17.151  pjsua_media.c  ......Call 0: stream #0 (audio) unchanged.
08:59:17.151  pjsua_media.c  ......Audio updated, stream #0: GSM (sendrecv)
08:59:17.151 timer_android.  .....Scheduling timer 1 of 8 in 0 ms @ 0x5bbc1624
08:59:17.183 pjsua_jni_addo  .....Get secure for media type 1
08:59:17.183 zrtp_android.c  .....jzrtp_getInfoFromContext : user data 12d56a0
08:59:17.183 zrtp_android.c  .....jzrtp_getInfoFromContext : user data 12d56a0
08:59:17.184    pjsua_aud.c  .....Conf connect: 2 --> 0
08:59:17.184    pjsua_aud.c  .....Conf connect: 0 --> 2
08:59:17.224   inv0x130000c  ....Received Response msg 200/INVITE/cseq=13425 
(rdata0x134e42c), sending ACK
08:59:17.224  tdta0x15a4710  ....Destroying txdata Request msg ACK/cseq=13424 
(tdta0x15a4710)
08:59:17.224       endpoint  ....Request msg ACK/cseq=13425 (tdta0x15a4710) 
created.
...
08:59:31.449 pjsua_jni_addo  .....Call 0 is DISCONNECTED [reason=200 (Normal 
call clearing)]
08:59:31.451 pjsua_jni_addo  .....Get secure for media type 1
08:59:31.451 zrtp_android.c  .....jzrtp_getInfoFromContext : user data 12d56a0
08:59:31.452 zrtp_android.c  .....jzrtp_getInfoFromContext : user data 12d56a0
08:59:31.503  pjsua_media.c  .....Call 0: deinitializing media..
08:59:31.503 timer_android.  .......Scheduling timer 1 of 8 in 1000 ms @ 
0x5bbc90ac
08:59:31.521  strm0x15a169c  .......JB summary:
  size=0/eff=0 prefetch=0 level=3
  delay (min/max/avg/dev)=20/500/45/48 ms
  burst (min/max/avg/dev)=1/5/2/0 frames
  lost=0 discard=56 empty=101
08:59:31.521  pjsua_media.c  .......Media stream call00:0 is destroyed
08:59:31.521 transport_zrtp  ......Media stop - encrypted packets: 0, decrypted 
packets: 0
08:59:31.521        icetp00  ......Stopping ICE, reason=media stop requested
08:59:31.521 transport_zrtp  ......Destroy - encrypted packets: 0, decrypted 
packets: 0
08:59:31.521        icetp00  ......ICE stream transport 0x13989f4 destroy 
request..
08:59:31.521 stuntp0x144e1e  .......STUN sock 0x1574374 request, ref_cnt=8

Logs from Linphone:
message: CALL_ACK
message: sent ZRTP Hello    4258
message: received ZRTP HelloACK 2
message: sent ZRTP Commit   4259
message: Received message:
INVITE sip:x@85.156.y.y SIP/2.0
...
a=zrtp-hash:1.10 cb4d...
...
message: Stopping ZRTP context
message: Destroying ZRTP wrapper
message: Destroying ORTP-ZRTP mutex
message: Destroying SRTP contexts
message: ORTP-ZRTP context destroyed
message: Audio MSTicker thread exiting
(Linphone has no feature "timestamps in logs")

Original comment by hvtaifwk...@gmail.com on 29 Mar 2013 at 7:22